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 um11_Lagerund 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.mdals Agent-Entry-Point - Vorlagen in
09_Vorlagen/(zentralisiert, niemals dezentral) - Kunden-Akten in
05_CRM/kunden/<kundenname>/(Kommunikations-Historie, Vertragsstand, Sonderkonditionen) - Kuratierte Indexe (
_index.mdpro 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 - Titeletc.) 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
-
_index.mdist 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). -
Christophs Naming-Konvention respektieren — der Agent muss
YYYY_MM_DD - Kunde - Titelals Event-Naming akzeptieren, nicht durchsetzen wollen dass esYYYY-MM_Kunde_Titelheisst. Die Konvention des Kunden ist die Konvention. -
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. -
System-Prompt muss klar machen welche Site zustaendig ist — bei Wissens-Fragen (Standards, Vorlagen, Stammdaten):
/sites/internzuerst. Bei Daten-Fragen (Event-Files, Bilder, Kalkulations-Excels): direkt OwnCloud, ggf. ueber_index.md-Link. -
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.
Related
- sharepoint-permissions-app-grant — Sites.Selected-Setup pro Site
- open-webui-konfigurations-quirks — Open WebUI-spezifische Gotchas
- kunde-openwebui-onboarding — Master-Pattern fuer Kunden-Setups, nutzt diese Architektur
- 2026-05 — Aufbau am 2026-05-14 + Lessons