SharePoint Meta-Layer als Architektur-Entscheidung

Bei VF und kuenftigen Kunden-Setups gibt es zwei SharePoint-Sites mit klar getrennten Rollen — nicht eine Site fuer alles.

Entscheidung

Zwei-Sites-Architektur:

  • /sites/OwnCloud (oder wie auch immer die gewachsene Site heisst beim Kunden) — DATEN-Layer. Hier leben die echten Files: Konzepte, Kalkulationen, Bilder, Vertraege, Excels, Praesentationen. Bleibt unveraendert beim Kunden, kein Migrations-Druck.

  • /sites/intern — META-Layer. Hier liegt was der Agent „weiss” um den Kunden sinnvoll zu unterstuetzen: Stammdaten, Standards, Routing, Vorlagen-Index, Kunden-Akten, Knowledge. Sub-Ordner-Struktur folgt Christophs Schema (00_Unternehmen … 99_Archiv), erweitert um 11_Lager und ggf. weitere kundenspezifische Bereiche.

Was kommt in den Meta-Layer:

  • Stammdaten (Firma, Rechnungsadresse, USt-IdNr, Team-Rollen)
  • Prozess-Beschreibungen in 10_Wissen/standards/ (wie macht VF Anfragen, Abrechnungen, Lager-Reservierungen)
  • Routing-File 10_Wissen/standards/_routing.md als Agent-Entry-Point
  • Vorlagen in 09_Vorlagen/ (zentralisiert, niemals dezentral)
  • Kunden-Akten in 05_CRM/kunden/<kundenname>/ (Kommunikations-Historie, Vertragsstand, Sonderkonditionen)
  • Kuratierte Indexe (_index.md pro Bereich) mit Direktlinks zu OwnCloud-Files
  • Game-Changer-Skill-Daten (z.B. Bestand-Snapshot, Reservierungs-Tabelle als Excel mit klarem Schema)

Was NICHT in den Meta-Layer kommt:

  • Echte Daten-Files (Excels mit 1000 Zeilen, GB-grosse Bilder, Videos, lange Word-Dokumente) — die bleiben in OwnCloud
  • Pointer-Ordner pro Event/Kunde — Doppelung ohne Mehrwert, _index.md-Tabellen mit Links reichen
  • Leere Sub-Ordner auf Vorrat — on-demand anlegen besser

Warum so

Gegen einzelne Site (alles in OwnCloud):

  • Standards/Routing wuerden zwischen 1 TB Daten verschwinden
  • Agent muesste die Operating-System-Files muehsam suchen statt sie direkt zu finden
  • Kunde wuerde an seiner gewachsenen Struktur weiter arbeiten, ohne Klarheit was „strukturiert” und was „gewachsen” ist

Gegen Vollmigration (alles in /sites/intern):

  • 1 TB umkopieren ist OneDrive-Sync-Stress + Quota-Belastung
  • Kunde muesste seine taegliche Arbeit neu lernen
  • Wir wuerden Christophs gewachsenes Operating-System (Konvention YYYY_MM_DD - Kunde - Titel etc.) brechen

Pro Zwei-Sites:

  • Klare Trennung Daten vs. Wissen
  • Kein Migrations-Stress beim Kunden — er arbeitet weiter wie gewohnt
  • Agent hat fokussierten Eintrittspunkt (_routing.md)
  • Meta-Layer ist klein (<10 MB), schnell zu synchronisieren, Backup-freundlich

Konsequenzen — wichtige Folge-Regeln

  1. _index.md ist der Default — pro Top-Level-Bereich ein kuratierter Index mit Direktlinks zur OwnCloud-Quelle. Nicht 65 Pointer-Ordner anlegen (wurde am 2026-05-14 erst gebaut + dann geloescht — Lesson: Doppelung vermeiden).

  2. Christophs Naming-Konvention respektieren — der Agent muss YYYY_MM_DD - Kunde - Titel als Event-Naming akzeptieren, nicht durchsetzen wollen dass es YYYY-MM_Kunde_Titel heisst. Die Konvention des Kunden ist die Konvention.

  3. Status via Ordner-Verschiebung in OwnCloud — Christoph nutzt !Stattgefunden/, !Abgesagt/, !Projekt_NEU/ als Status-Folder. Der Agent erkennt das + respektiert es. Keine separate Status-Pflege im Meta-Layer.

  4. System-Prompt muss klar machen welche Site zustaendig ist — bei Wissens-Fragen (Standards, Vorlagen, Stammdaten): /sites/intern zuerst. Bei Daten-Fragen (Event-Files, Bilder, Kalkulations-Excels): direkt OwnCloud, ggf. ueber _index.md-Link.

  5. Permissions per-Site granular (Sites.Selected) — der mcp-m365-App muss auf BEIDEN Sites Permission granted werden. Siehe sharepoint-permissions-app-grant.

Anti-Pattern erkennen

Ueberproduktion vermeiden: bei „heute alles fertig”-Modus den Reflex haben, viele Pointer/Vorrats-Strukturen anzulegen. Frage statt dessen: „bringt das aktiven Nutzen heute oder ist das nur Symmetrie?“. Wenn nur Symmetrie → on-demand.