SharePoint + OpenWebUI VF doppelungs-frei integrieren

Kontext

VF hat zwei parallele Routing-Welten am laufen:

SharePoint Workshop/VibeFactory/CLAUDE.md (16 KB, von Christoph gepflegt) — Mensch-lesbares Onboarding + Routing fuer die VF-Crew die in claude.ai Cowork mit Files arbeitet. Enthaelt Firma-Stammdaten, Prozessmanager-Tabelle, Ordnerstruktur, Artifact-Design-CSS, Konventionen, Projekt-Status. Christoph hat einen Refactor-Plan v2 (2026-05-12_Fahrplan_CLAUDE-md-Refactor_v2.html) der CLAUDE.md auf reine Routing-Tabelle schrumpft, Details wandern in 09_Standards/Regeln/Anleitungen/Vorlagen/ + _context.md pro Bereich.
OpenWebUI VF (~/source/apps/open-webui-vf/prompts/) — LLM-System-Prompt-Architektur mit _base.txt (15 XML-Bloecke: Identitaet, Stammdaten, Mail-Workflow „nur Drafts”, Excel-Workflow, Diagramme-Regeln, Sicherheits-Grenze etc.) plus Persona-Variants (Julia/Nova/Cosmo). Tool-Whitelists pro Model, globale Send-Sperre. build.py baut Prompts + pusht via Admin-API.

Beide Welten haben Routing-Tabellen, aber ihre Aufgaben sind verschieden: SharePoint adressiert Mensch-User-im-Browser, OpenWebUI adressiert das LLM via System-Prompt mit strikteren Regeln.

Audit-Ergebnis (Doppelungs-Analyse 2026-05-20):

Inhalt	SharePoint	OpenWebUI	Echte Doppelung?
Firma-Stammdaten	ja	ja (`<vf_stammdaten>`)	ja
Prozessmanager-Tabelle	ja	nicht zwingend	nur falls dup
Artifact-Design CSS	komplett	indirekt via `<inline_visualisierungen>`	ja, latent
Dateinamen-Konvention	ja	indirekt	klein
Mail-Workflow „nur Drafts”	nein	ja	nicht doppelt
Tool-Whitelists / Priorität	nein	ja	nicht doppelt
Ordnerstruktur 00-99	ja	nicht zwingend	nur falls dup
Projekt-Status LinkedIn/Stadtfest	ja	nein	nicht doppelt

Nur drei Stellen sind echte Doppelungen: Firma-Stammdaten, Artifact-Design-CSS, Dateinamen-Konvention. Alles andere ist disjunkt.

Ziel

Doppelungs-freie Integration mit klarer Rollenverteilung. Jede Information hat genau einen Heimatort, die andere Welt referenziert. SharePoint bleibt Source-of-Truth fuer Mensch-Wissen (Christoph als Owner), OpenWebUI bleibt Source-of-Truth fuer LLM-Verhaltens-Code (Marvin als Owner). Bei VF-Daten-Aenderung muss Marvin den OpenWebUI-Prompt NICHT updaten — er liest aus SharePoint via mcp-vault.

Rollenverteilung

Inhalt	Heimat	Andere Welt
Firma, Pitch, Team, Prozessmanager	SharePoint `CLAUDE.md` (Christoph)	OpenWebUI laedt on-demand via `mcp-vault`
Ordnerstruktur + Bereichs-Spielregeln	SharePoint `_context.md` pro Bereich (nach Refactor)	OpenWebUI laedt `_context.md` per Tool-Call
Artifact-Design CSS	SharePoint `09_Standards/Regeln/Artifact-Design.md` (nach Refactor)	OpenWebUI verweist drauf in `<output_stil>`
Dateinamen, Sprache, Versionierung	SharePoint `09_Standards/Regeln/Dateinamen-und-Sprache.md`	OpenWebUI `_base.txt` referenziert plus 3-4 wichtigste inline (bewusste Mini-Doppelung fuer Performance)
Mail-Workflow „nur Drafts”	OpenWebUI `_base.txt` `<mail_workflow>`	SharePoint-CLAUDE.md erwaehnt nur „Mail-Verhalten siehe vf-chat-Prompt”
Tool-Whitelists + Persona-Models	OpenWebUI Custom-Model-Config + `build.py`	SharePoint erwaehnt nur „3 Personas: Julia/Nova/Cosmo — wofuer welche”
Projekt-Status (Stadtfest, LinkedIn)	SharePoint `_context.md` im jeweiligen Bereich	OpenWebUI Persona-Variant verweist auf Pfad, laedt on-demand

Drei Anti-Doppelungs-Regeln

Stammdaten leben in SharePoint, OpenWebUI laedt sie via Tool. Statt <vf_stammdaten> im _base.txt hardzucoden, kommt eine Anweisung rein: „bei Bedarf nach Firma-Stammdaten lies Workshop/VibeFactory/CLAUDE.md Section ‚Über dieses Verzeichnis’“.
Regeln/Anleitungen leben in SharePoint, OpenWebUI verweist mit Direktlink. Wenn ein Verhalten geaendert wird (z.B. neue Anleitung „Wie schreibe ich ein Angebot?”), legt Christoph oder Marvin die .md in SharePoint an — der Prompt zieht sie automatisch. Spart Build-Push-Zyklus pro Anleitung.
Verhaltens-Code bleibt in OpenWebUI. Send-Sperre, Tool-Prioritaet, Workflow-Disziplin sind LLM-Code, kein Mensch-Wissen. Gehoeren NICHT in die mensch-lesbare SharePoint-CLAUDE.md.

Phasen

Phase 0 — Vor-Bedingung pruefen (5 Min)

Pruefen ob folgende drei Dinge stimmen — wenn nein, vorher fixen:

mcp-vf-hosted enthaelt m365-Sub-MCP mit den noetigen SharePoint-Tools (list_drive_items, get_drive_item, search_files, download_file — bestaetigt aus heutigem Audit 2026-05-20).
OpenWebUI-User Andre + Christoph haben Tool-Whitelist-Eintrag fuer mindestens sharepoint_search_files + sharepoint_get_drive_item (Standard heute in Julia/Cosmo).
Im Browser ist vf-chat.agenticventures.de erreichbar fuer Marvin als Admin.

Wenn 1 oder 2 nicht: Notes in intern/projekte/openwebui-vf/_index.md ergaenzen + zuerst fixen. Wenn 3 nicht: AWS-Profile pruefen.

Phase A — SharePoint-CLAUDE.md neue Section „Frontends” (10 Min)

Wer: Marvin schlaegt vor in Mail an Christoph, Christoph genehmigt + traegt selbst ein (Christoph ist Vault-Owner — Regel aus vf-vault-architektur.md).

Was: Neue Section in SharePoint-CLAUDE.md zwischen „Tools & Integrationen” und „Aktueller Projekt-Status” einfuegen:

## Frontends — wo welches Verhalten lebt
 
VF hat zwei Claude-Frontends auf demselben SharePoint-Vault:
 
| Frontend | URL | Wer | Wofuer |
|---|---|---|---|
| claude.ai Cowork | claude.ai (pro-User-Login) | Christoph + Andre + Julian + Felix | Mensch-im-Browser, Artifacts in Pinned-Sidewing, Canva-Direkt-Integration |
| vf-chat (OpenWebUI) | https://vf-chat.agenticventures.de | Marvin als Admin, schrittweise das Team | LLM-Backend mit 3 Personas, Multi-User-Workflows, Send-Sperre |
 
**Drei Personas in vf-chat:**
 
- `vf-julia` (Buchhaltung) — Andre + Christoph, voller Papierkram-Zugriff
- `vf-nova` (Design) — alle, Replicate-Bildgenerierung
- `vf-cosmo` (Projektmanagement) — alle, allgemeines Office plus TicketPAY
 
**Was vf-chat NICHT kann (Absicht):**
 
- Mails senden — vf-chat legt nur Drafts in Outlook ab, der User klickt selbst in Outlook auf „Senden"
- Buchhaltung fuer Felix/Julian/Andere — nur Julia (= Andre + Christoph)
 
**Source-of-Truth fuer vf-chat-Verhalten:** `~/source/apps/open-webui-vf/prompts/` (Marvin als Owner). Wenn ein vf-chat-Verhalten geaendert werden soll: Anfrage an Marvin.

Wenn Christoph zustimmt: Christoph traegt selbst ein (er kennt die OneDrive-Sync-Logik am besten). Wenn er sagt „leg du das ein”: Marvin via mcp-m365-Write-Tool, vorher Backup-Kopie der bisherigen CLAUDE.md lokal.

Done-Kriterium: Section live in SharePoint, sichtbar fuer alle VF-User.

Phase B — OpenWebUI `_base.txt` umstellen auf SharePoint-Referenzen (15 Min)

Wer: Marvin in ~/source/apps/open-webui-vf/prompts/_base.txt.

Aenderungen am _base.txt:

<vf_stammdaten>-Block ersetzen durch <vf_stammdaten_quelle>:

<vf_stammdaten_quelle>
Bei Bedarf nach Firma-Stammdaten (Adresse, GF, Team, Prozessmanager-Zuordnung, Pitch, Spezialgebiete, Kennzahlen) IMMER zuerst die Source-of-Truth lesen statt zu raten:

Pfad: `Workshop/VibeFactory/CLAUDE.md` auf `vibefactorygbr.sharepoint.com`
Tool: `sharepoint_search_files` mit query="CLAUDE.md" + path:/Workshop/VibeFactory ODER direkter `sharepoint_get_drive_item` wenn item_id bekannt
Lesen via downloadUrl oder mcp-vault Tool (siehe `<sharepoint_direktlinks>` unten).

Christoph (christoph@vibe-factory.de) ist Vault-Owner — bei Inkonsistenzen ihn fragen, nicht selbst korrigieren.
</vf_stammdaten_quelle>

<output_stil> ergaenzen um Verweis auf Artifact-Design-CSS:

<output_stil>
[...bisheriger Inhalt...]

Bei HTML-Reports, Inline-Visualisierungen, Diagrammen: der verbindliche CSS-Stil liegt in SharePoint unter `Workshop/VibeFactory/09_Standards/Regeln/Artifact-Design.md` (sobald Christophs Refactor durch — falls noch nicht: lies die Section „Artifact-Design – verbindlicher Stil" in `Workshop/VibeFactory/CLAUDE.md`). KEIN eigenes Design erfinden, KEINE Akzentfarben, KEINE box-shadow-Card-Designs.
</output_stil>

<arbeitsweise> ergaenzen um Konventions-Verweis:

<arbeitsweise>
[...bisheriger Inhalt...]

Konventionen fuer Sprache, Dateinamen, Versionierung: gemaess `Workshop/VibeFactory/CLAUDE.md` Section „Konventionen fuer Claude" (bzw nach Refactor `09_Standards/Regeln/Dateinamen-und-Sprache.md`). Kernregeln inline (Performance — Verifikation bei Konflikt):
- Dateinamen `YYYY-MM-DD_Thema_Variante.ext`, Umlaute erlaubt, keine Leerzeichen am Anfang
- Sprache deutsch ausser Kunden-Kontext fordert Englisch
- Niemals loeschen ohne Rueckfrage
- Versionierung statt In-Place-Update (`_v2`, `_final`)
</arbeitsweise>

<sharepoint_direktlinks> ergaenzen um expliziten Lese-Pfad fuer CLAUDE.md:

<sharepoint_direktlinks>
[...bisheriger Inhalt...]

Wichtiger Quellpfad — SharePoint-Vault-Wurzel: `https://vibefactorygbr.sharepoint.com/sites/OwnCloud/Freigegebene%20Dokumente/Workshop/VibeFactory/`
- CLAUDE.md: ebd. + `CLAUDE.md` (Firma, Routing, Konventionen)
- Ordnerstruktur-Detail: ebd. + `2026-04-27_Ordnerstruktur_Vorschlag_v1.md`
- Aktuelle Refactor-Phase: ebd. + `2026-05-12_Fahrplan_CLAUDE-md-Refactor_v2.html`
Lese-Disziplin: bei Stammdaten-Fragen, Bereichs-Spielregeln, Artifact-Design IMMER zuerst diese Files lesen — nicht aus dem Prompt antworten.
</sharepoke_direktlinks>

build.py --dry-run ausfuehren, _base.txt-Diff visuell pruefen.
build.py --push wenn Diff stimmig.

Done-Kriterium: drei Persona-Models live mit neuer _base.txt, in OpenWebUI Admin-UI ist „letzte Aenderung” auf heute gesetzt.

Phase C — OpenWebUI smoke-testen (10 Min)

Wer: Marvin in OpenWebUI Admin-Account.

Testfaelle:

In vf-cosmo: „Wer ist VF, was machen die, wie ist das Team aufgestellt?”
- Erwartung: Modell ruft sharepoint_search_files oder sharepoint_get_drive_item fuer CLAUDE.md auf, antwortet basierend auf dem File-Inhalt mit korrekten Stammdaten (Hamm-Adresse, Andre+Julian+Christoph, GmbH). KEIN Hardcoded-Antwort aus dem Prompt.
In vf-cosmo: „Welche Personas gibt es in vf-chat und wofuer?”
- Erwartung: Modell antwortet aus der Prompt-Doku oder zieht SharePoint-CLAUDE.md (nach Phase A enthaelt sie die Antwort). Drei Personas korrekt benannt.
In vf-nova: „Erstelle einen Mockup-Report fuer Stadtfest Ennigerloh als HTML-Artifact”
- Erwartung: Modell verwendet den CSS-Stil aus Workshop/VibeFactory/CLAUDE.md (laedt die Section bevor es das HTML schreibt). KEINE eigenen Farben.

Wenn Test 1 fehlschlaegt: Tool-Whitelist fuer Cosmo erweitern um sharepoint_search_files + sharepoint_get_drive_item + sharepoint_download_file. Falls schon drin: Prompt-Block <vf_stammdaten_quelle> ueberpruefen ob die Anweisung zwingend genug formuliert ist („IMMER zuerst” statt „bei Bedarf”).

Done-Kriterium: alle drei Tests gruen, in Chat-Historie sichtbar dass Tool-Calls passieren.

Phase D — Falls Christophs Refactor noch nicht durch (Optional, ~30 Min)

Trigger: Wenn nach 1-2 Wochen 09_Standards/Regeln/Artifact-Design.md noch nicht existiert.

Wer: Marvin nach Absprache mit Christoph.

Was: Marvin legt die drei Standards-Files an (initiale Befuellung aus den entsprechenden CLAUDE.md-Sections):

Ziel-File	Quelle	Inhalt
`Workshop/VibeFactory/09_Standards/Regeln/Artifact-Design.md`	SharePoint-CLAUDE.md Section „Artifact-Design – verbindlicher Stil”	CSS-Block + Verbote, 1:1 uebernommen
`Workshop/VibeFactory/09_Standards/Regeln/Dateinamen-und-Sprache.md`	SharePoint-CLAUDE.md Section „Konventionen fuer Claude”	Sprache, Dateinamen, Niemals-loeschen, Versionen
`Workshop/VibeFactory/09_Standards/Regeln/Tools-und-Integrationen.md`	SharePoint-CLAUDE.md Section „Tools & Integrationen”	Canva-Template-ID, WebSearch, M365, LinkedIn-Hinweis

Ablauf via sharepoint_upload_text_file (Tool ist in OpenWebUI-Stack vorhanden). Christoph bekommt Mail-Notiz „habe drei Files in 09_Standards/Regeln/ angelegt, von deinem Refactor-Plan abgeleitet — pruef mal kurz”.

Wenn Christoph dagegen ist: Files wieder loeschen, Phase D faellt ersatzlos weg. OpenWebUI-Prompts bleiben dann auf CLAUDE.md verweisen statt auf die Regel-Files.

Done-Kriterium: drei Files existieren in SharePoint, OpenWebUI _base.txt aktualisiert um direkt auf die neuen Pfade zu zeigen statt auf die alte CLAUDE.md-Section.

Phase E — Verlinkung in AV-Vault dokumentieren (10 Min)

Wer: Marvin in AV-Vault.

Was:

intern/projekte/openwebui-vf/_index.md Section „Cross-Refs” — Eintrag ergaenzen - [[plans/2026-05-20-sharepoint-openwebui-integration]] — Doppelungs-frei-Plan
intern/projekte/openwebui-vf/vf-vault-architektur.md Section „OFFENE PUNKTE” — Punkt 1 (Christophs Reaktion auf 5 Best-Practices) erweitern: „Stand 2026-05-20: SharePoint-OpenWebUI-Integrations-Plan freigegeben, siehe plans/2026-05-20-sharepoint-openwebui-integration.md. Sprint-2a mcp-vault ist Voraussetzung, danach Phase A-E.”
intern/kunden/vibe-factory.md — kurzer Hinweis in Section „Setup” oder „Tools” auf die Integrations-Doku, damit Marvin bei spaeteren VF-Anfragen den Pfad findet.

Done-Kriterium: Drei Cross-Refs eingetragen, last_reviewed in den Files aktualisiert.

Aufwand

Phase	Aufwand	Wer
0 — Vor-Bedingung pruefen	5 Min	Marvin
A — SharePoint-Section „Frontends”	10 Min Marvin + Christoph-Genehmigung	Marvin schlaegt vor, Christoph traegt ein
B — OpenWebUI `_base.txt` umstellen	15 Min	Marvin
C — Smoke-Test	10 Min	Marvin
D — Standards-Files anlegen (optional)	30 Min	Marvin nach Christoph-Absprache
E — Cross-Refs in AV-Vault	10 Min	Marvin
Gesamt ohne D	~50 Min
Gesamt mit D	~80 Min

Hinweis: Phase A braucht Christoph als Co-Aktion. Wenn er gerade nicht erreichbar ist, koennen B + C + E unabhaengig laufen (B verweist dann auf den heutigen CLAUDE.md-Stand, nicht auf Refactor-Endzustand).

Risiken + Gegenmassnahmen

Risiko	Wahrscheinlichkeit	Gegenmassnahme
OpenWebUI ruft das Stammdaten-Tool nicht zuverlaessig auf, sondern halluziniert	mittel	Phase C Smoke-Test verifiziert das. Wenn negativ: `<vf_stammdaten_quelle>` zwingender formulieren („MUSST” statt „solltest”), Tool-Aufruf-Pfad in System-Prompt-Beispiel zeigen
Christoph lehnt die neue „Frontends”-Section ab oder hat eigene Vorstellungen	niedrig (sein Pattern-Match-Verhalten ist konstruktiv)	Section als Vorschlag formulieren, Christoph kann umformulieren — Hauptsache die drei Personas + Send-Sperre sind erwaehnt
`mcp-vault` (Sprint 2a) ist noch nicht durch — Stammdaten-Lookup geht nur ueber `mcp-m365`-Tools	hoch (Sprint 2a Block 1.1 done, 1.2 wartet)	bis `mcp-vault` live ist: Prompt verweist auf `sharepoint_`-Tools aus mcp-vf-hosted. Lese-Performance ist langsamer (Excel-Range-Read statt Cached-Md-Read) aber funktional. Nach Sprint-2a-Abschluss `_base.txt` updaten auf `mcp_vault_`-Tools
Doppelung schleicht sich wieder ein, wenn jemand spaeter unbewusst Inhalte spiegelt	mittel	Diese Plan-Doku als Source-of-Truth fuer die Rollenverteilung pflegen. Bei jedem `welle-X`-Plan-Review pruefen ob neue Inhalte in der falschen Welt landen
OneDrive-Sync verzoegert SharePoint-Aenderung — VF-User sehen alte CLAUDE.md fuer Minuten/Stunden	niedrig	Nicht zeitkritisch. Bei Bedarf in MS-Teams kurz ankuendigen „CLAUDE.md aktualisiert”

Was wir NICHT machen

Keine zweite CLAUDE.md anlegen (z.B. eine im OpenWebUI-Repo). Eine pro Welt, klar abgegrenzt.
Keinen _base.txt-Content nach SharePoint kopieren. Das ist LLM-Code, kein VF-Mitarbeiter liest XML-Bloecke.
Keinen automatischen Sync zwischen den beiden CLAUDE.md-Welten. Sync = noch mehr Drift-Risiko.
Kein Eingriff in Christophs Refactor-Plan v2. Er entscheidet wann Phase A-G aus seinem Plan durchlaeuft. Wir reagieren darauf.
Keine VF-Daten in OpenWebUI-Prompt hardcoden. Auch nicht „nur kurz die Adresse fuer Performance”.

Done-Definition (gesamtplan)

Phase A: SharePoint-CLAUDE.md hat die neue „Frontends”-Section, Christoph hat zugestimmt.
Phase B: OpenWebUI _base.txt hat keinen <vf_stammdaten>-Block mehr, sondern <vf_stammdaten_quelle>. Andere Bloecke verweisen auf SharePoint statt zu hardcoden.
Phase C: alle drei Smoke-Tests gruen.
Phase E: drei Cross-Refs im AV-Vault gesetzt.
Bei Folgesession mit VF: bei „wer ist VF” muss das LLM auf SharePoint-CLAUDE.md zugreifen, nicht aus dem Prompt antworten.

Cross-Refs

vf-vault-architektur — Big-Picture VF-Vault-Architektur (Drei-Phasen-Roadmap, beide Frontends parallel)
sprint-2a-spec — mcp-vault Sub-MCP fuer effizientes Vault-Lesen (Voraussetzung fuer optimale Lese-Performance, aber nicht-blockend)
permission-architektur — System-Prompt-Architektur OpenWebUI VF (3 Personas, Tool-Whitelists, Send-Sperre)
sprint-2-master-plan — gesamter Sprint-2-Plan, Teil 2b „vf-context Sub-MCP + Dynamic-Prompt-Building” ist verwandt
mcp-vault — Skelett-Repo
vibe-factory — VF-Kundenfile
SharePoint: https://vibefactorygbr.sharepoint.com/sites/OwnCloud/Freigegebene%20Dokumente/Workshop/VibeFactory/CLAUDE.md
SharePoint: https://vibefactorygbr.sharepoint.com/sites/OwnCloud/Freigegebene%20Dokumente/Workshop/VibeFactory/2026-05-12_Fahrplan_CLAUDE-md-Refactor_v2.html

Naechster Schritt

Marvin gibt Freigabe (oder korrigiert das Plan-Skelett). Bei Freigabe: Phase 0 + B + C in einer Session (~30 Min, kein Risiko, keine externe Abstimmung noetig), parallel Mail-Draft an Christoph fuer Phase A.

Wenn Marvin sagt „leg los”: ich starte mit Phase 0 (5 Min Vor-Bedingungen pruefen) und Phase B (15 Min _base.txt-Edit + Build), danach Smoke-Test Phase C.

Agentic Ventures Wiki

Explorer

SharePoint-Vault und OpenWebUI-VF doppelungs-frei integrieren

SharePoint + OpenWebUI VF doppelungs-frei integrieren

Kontext

Ziel

Rollenverteilung

Drei Anti-Doppelungs-Regeln

Phasen

Phase 0 — Vor-Bedingung pruefen (5 Min)

Phase A — SharePoint-CLAUDE.md neue Section „Frontends” (10 Min)

Phase B — OpenWebUI `_base.txt` umstellen auf SharePoint-Referenzen (15 Min)

Phase C — OpenWebUI smoke-testen (10 Min)

Phase D — Falls Christophs Refactor noch nicht durch (Optional, ~30 Min)

Phase E — Verlinkung in AV-Vault dokumentieren (10 Min)

Aufwand

Risiken + Gegenmassnahmen

Was wir NICHT machen

Done-Definition (gesamtplan)

Cross-Refs

Naechster Schritt

Graphansicht

Inhaltsverzeichnis

Agentic Ventures Wiki

Explorer

SharePoint-Vault und OpenWebUI-VF doppelungs-frei integrieren

SharePoint + OpenWebUI VF doppelungs-frei integrieren

Kontext

Ziel

Rollenverteilung

Drei Anti-Doppelungs-Regeln

Phasen

Phase 0 — Vor-Bedingung pruefen (5 Min)

Phase A — SharePoint-CLAUDE.md neue Section „Frontends” (10 Min)

Phase B — OpenWebUI _base.txt umstellen auf SharePoint-Referenzen (15 Min)

Phase C — OpenWebUI smoke-testen (10 Min)

Phase D — Falls Christophs Refactor noch nicht durch (Optional, ~30 Min)

Phase E — Verlinkung in AV-Vault dokumentieren (10 Min)

Aufwand

Risiken + Gegenmassnahmen

Was wir NICHT machen

Done-Definition (gesamtplan)

Cross-Refs

Naechster Schritt

Graphansicht

Inhaltsverzeichnis

Phase B — OpenWebUI `_base.txt` umstellen auf SharePoint-Referenzen (15 Min)