meldestelle/docs/01_Architecture/Proposals/C-3_Docs-Strukturvorschlag.md
2026-04-03 23:19:28 +02:00

4.4 KiB
Raw Blame History

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 „DocsasCode“ und „OfflineFirst“ 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- & HowToGuides
  • 03_Domain/ Fachliche Referenzen, Glossar, Regelwerke
  • 04_Agents/ Playbooks, Roadmaps, Sitzungsdokus der Agenten
  • 05_Backend/ API, DBSchema, ServicesDoku
  • 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. HTMLTemplates, 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/**/*.zipdocs/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|*.pngdocs/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. RedirectStubs (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.
  • HTMLTemplates (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 TextDoku und Medien → bessere Lesbarkeit, schnellere Diffs.
  • Bessere Skalierbarkeit der zeitlichen Inhalte (Reports/Journal) → einfache Auffindbarkeit.
  • Geringes Bruchrisiko dank RedirectStubs in Phase 2.

Nächste Schritte

  • Review durch 🏗️ Architect
  • Nach Freigabe: Migrations-Tickets je Teilbereich (Frontend, Reports, Assets)