Update 2026-05-18 — Persona-Pivot
Der urspruengliche Plan sah 2 Custom Models (vf-sonnet-allgemein + vf-sonnet-buchhaltung) vor. Marvin hat den Pivot auf 3 Persona-Models entschieden (siehe Welle-4-Update). Plan-Sections unten gelten weiter fuer die Logik (Groups, Send-Sperre, Tool-Whitelist-Pattern), aber Model-IDs/Namen sind:
- vf-julia (Julia/Buchhaltung) statt
vf-sonnet-buchhaltung— Andre + Christoph - vf-nova (Nova/Design) — neu, alle User
- vf-cosmo (Cosmo/Projektmanagement) statt
vf-sonnet-allgemein— alle User
Deployed 2026-05-18 via Admin-API: drei Custom Models live, alte vf-sonnet-Model + Backend-Models (haiku, opus) + Base + Arena auf hidden. Banner aktualisiert.
Noch offen:
- Julia auf Group
buchhaltungrestricten (Andre + Christoph) — Group muss in Admin-UI angelegt werden, dann API-Call zumaccess_control-Setzen - ApplicationAccessPolicy in Exchange Online (Auth-Haertung Schicht 1)
- MCP-Code-Patch fuer User-Header-Scope-Lock (Schicht 2)
Permission-Architektur Open WebUI VF
Ausgangslage: heute haben alle VF-User dasselbe Custom Model vf-sonnet mit allen 16 Core-Tools inkl. Papierkram (Buchhaltung) und Mail-Senden. Das soll rollenbasiert werden — nicht jeder darf alles.
Ziele
- Felix sieht keine Buchhaltungs-Tools. Andere Crew/Praktikanten auch nicht. Buchhaltung ist Andre + Christoph.
- Kein Agent sendet Mails raus. Drafts ja, Senden niemand. Human-in-the-Loop: User klickt in Outlook selbst auf „Senden”.
- Standard-Tools (SharePoint Read+Write Excel/PowerPoint/Files, Mail-Drafts, Web-Suche, Replicate-Bildgenerierung, TicketPAY, Code-Interpreter) sind fuer alle.
- Praktikanten-Onboarding muss easy sein — Standard-Workflow, kein Custom-Setup pro Person.
- Source-of-Truth fuer System-Prompts bleibt das Repo (
~/source/apps/open-webui-vf/prompts/), nicht die Open-WebUI-UI.
Nicht-Ziele
- Keine Schicht-2-RBAC im MCP-Code in dieser Iteration. Open-WebUI-Group-Permissions reichen fuer VF-Trust-Level. MCP-User-Header-Scope-Lock kommt als separates Folgeprojekt wenn Compliance es verlangt.
- Keine Delegated OAuth pro User in M365. Application-Permissions + ApplicationAccessPolicy bleiben — Schicht-1-Sicherheit.
- Keine Konvertierung von hello@ zu Shared Mailbox in diesem Plan. Optional spaeter.
Model-Matrix
Zwei Custom Models, klar abgegrenzt:
| Model | Zweck | Tool-Whitelist | Access-Control | Default fuer |
|---|---|---|---|---|
vf-sonnet-allgemein | Office-Assistent ohne Buchhaltungs-Zugriff | SharePoint (alle inkl. Excel-Write, Drafts, Web-Suche), TicketPAY (alle), Replicate (alle), search_tools | Group: crew UND buchhaltung (alle sehen es) | Felix, Johanna, Julian, Wladimir, Flemming, Praktikanten |
vf-sonnet-buchhaltung | Erweiterung um Papierkram-Tools | wie allgemein + alle papierkram_* Tools | Group: buchhaltung (nur Andre + Christoph) | Andre, Christoph (zusaetzlich zu allgemein) |
Andre + Christoph sehen beide Models im Picker — sie waehlen je nach Anfrage. Felix sieht nur vf-sonnet-allgemein.
Tool-Whitelist vf-sonnet-allgemein
SharePoint (M365) — read + write, ohne Senden:
sharepoint_list_sites
sharepoint_get_site
sharepoint_list_drive_items
sharepoint_search_files
sharepoint_get_drive_item
sharepoint_download_file
sharepoint_create_folder
sharepoint_upload_text_file
sharepoint_read_excel_workbook_metadata
sharepoint_read_excel_range
sharepoint_read_excel_used_range
sharepoint_read_excel_table
sharepoint_write_excel_range
sharepoint_add_excel_worksheet
sharepoint_list_lists
sharepoint_query_list_items
sharepoint_list_mail_folders
sharepoint_list_messages
sharepoint_get_message
sharepoint_search_messages
sharepoint_list_attachments
sharepoint_download_attachment
sharepoint_create_draft
sharepoint_web_search
sharepoint_web_fetch_url
TicketPAY (alle 14):
ticketpay_event_bilanz
ticketpay_list_api_keys
ticketpay_list_cancellations
ticketpay_list_donations
ticketpay_list_employees
ticketpay_list_event_campaigns
ticketpay_list_events
ticketpay_list_fees
ticketpay_list_orders
ticketpay_list_products
ticketpay_list_shops
ticketpay_list_sold_articles
ticketpay_list_tickets
ticketpay_list_transactions
ticketpay_list_vouchers
ticketpay_raw_get
Replicate (Bild-Generierung):
replicate_create_prediction
replicate_get_prediction
replicate_wait_for_prediction
replicate_list_predictions
replicate_cancel_prediction
Meta:
search_tools
Tool-Whitelist vf-sonnet-buchhaltung
Alles aus vf-sonnet-allgemein PLUS alle papierkram_* Tools (~70). Insbesondere:
papierkram_list_invoices,papierkram_get_invoice,papierkram_create_invoice,papierkram_update_invoicepapierkram_list_vouchers,papierkram_get_voucher,papierkram_create_voucher,papierkram_upload_voucher_documentpapierkram_list_companies,papierkram_get_company,papierkram_create_companypapierkram_list_projects,papierkram_list_time_entriespapierkram_monatsabschluss,papierkram_offene_posten,papierkram_kunde_uebersichtpapierkram_list_bank_transactions- (Liste vollstaendig zu pflegen —
papierkram_*als Wildcard wenn Open WebUI das unterstuetzt, sonst alle einzeln)
Global gesperrt (in keinem Model)
Diese drei Tools tauchen in KEINEM Model auf — Sonnet kann nicht senden, Punkt:
sharepoint_send_mail
sharepoint_send_draft
sharepoint_reply_message
System-Prompt-Architektur
Source-of-Truth: ~/source/apps/open-webui-vf/prompts/. Aufgeteilt in Basis + Varianten:
~/source/apps/open-webui-vf/prompts/
├── _base.txt # gemeinsamer Anfang fuer alle Models
├── vf-sonnet-allgemein.txt # _base + allgemeine Workflows
├── vf-sonnet-buchhaltung.txt # _base + Papierkram-Workflows
└── build.py # baut finale Prompts + pusht in Open WebUI Admin-API
_base.txt — gemeinsamer Anfang
Enthaelt alles was in beiden Models gilt:
<identitaet>(vf-sonnet, VF-Team, Hosting-Kontext) — leicht abstrahiert ohne MCP-Liste<vf_stammdaten>(Firma, Team, Sites)<kontext>(Datum, User-Info-Platzhalter)<keine_halluzinationen>(Tool-First-Disziplin)<fehler_resilienz><werkzeug_sprache><sharepoint_direktlinks>- NEU:
<mail_workflow>— umgeschrieben auf „nur Drafts, niemals senden”:
<mail_workflow>
Email-Bearbeitung ist ein Default-Use-Case. Folge dieser Disziplin:
DRAFT ERSTELLEN (jederzeit erlaubt):
- `sharepoint_create_draft` legt eine Draft-Mail in Outlook an. Du hast KEINE Werkzeuge zum Senden, Versenden, Reply-Senden oder Draft-Versenden. Das ist Absicht: alle Mails verlassen das Haus nur, wenn ein Mensch in Outlook auf „Senden" klickt.
- Pflicht-Felder im Draft: `to`, `subject`, `body`, optional `cc`/`bcc`.
- Body-Aufbau (deutsche Standardform): Anrede mit Vornamen wenn aus CRM/Mail-Historie bekannt, Hauptteil knackig, Gruss mit Vorname des Senders + Firmenname VibeFactory GmbH.
- Niemals Tagessaetze, Margen, Crew-Bewertungen in externen Mails.
WENN DER USER SAGT „SCHICK DIE MAIL JETZT":
- NICHT versuchen ein Send-Tool aufzurufen — gibt es nicht.
- Erklaere ehrlich: „Ich kann Mails nur als Draft anlegen, nicht senden. Die Draft liegt in deinem Outlook-Postausgang als Entwurf — oeffne sie dort und klick auf Senden."
- Optional: Direktlink in Outlook angeben wenn aus dem Draft-Tool-Output ableitbar.
LESEN:
- `sharepoint_list_messages` mit Filter (`from`, `to`, `subject`, `search`) fuer Postfach-Lookup.
- `sharepoint_search_messages` fuer Volltext-Suche ueber alle Folder.
- Bei „antworte auf die Mail von X": erst Mail finden, dann Inhalt zusammenfassen, dann Reply-Draft via `sharepoint_create_draft` mit passendem Subject („Re: ...") und `to` auf den Original-Sender.
ANHAENGE:
- `sharepoint_list_attachments` + `sharepoint_download_attachment` fuer Files aus Mails.
- Anhaenge >3 MB brauchen Upload-Session — nur fuer kleine Files direkt machbar.
</mail_workflow>
<excel_workflow>(read/write, NEU: kein Bestaetigungs-Gate fuer Write — Marvin hat klargestellt dass alle Excel/PowerPoint frei nutzen sollen, also kein „erst preview, dann go”)<code_interpreter_files><diagramme_und_reports>(HTML-Default, kein Mermaid)<inline_visualisierungen>(HTML/SVG-Code-Blocks fuer Designs/Mockups)<arbeitsweise><sicherheits_grenze><vorsicht_finanzberatung><output_stil>
vf-sonnet-allgemein.txt
Header verweist auf _base, dann nur Use-Case-spezifische Ergaenzungen:
{{include _base.txt}}
<werkzeug_prioritaet>
1. Events, Tickets, Verkaeufe → TicketPAY (ticketpay_*)
2. Emails, Kalender, SharePoint-Files, Excel-Inhalte → Microsoft 365 (sharepoint_*)
3. Bild-/Video-Generierung (Designs, Mockups, Social-Posts, Moodboards, Logos) → Replicate (replicate_*)
4. Python-Berechnungen, PDF-Erzeugung, Diagramme → Code-Interpreter
5. Web-Suche → sharepoint_web_search / sharepoint_web_fetch_url
Buchhaltung, Belege, Rechnungen, Spesen: du hast KEINEN Zugriff auf das Papierkram-System. Wenn die Frage Buchhaltung betrifft („was hat X gekostet?", „welche Rechnungen sind offen?"): sag ehrlich „dafuer bin ich nicht eingerichtet — frag Andre oder Christoph, oder wechsle im Model-Picker oben links auf `vf-sonnet-buchhaltung` falls du dort Zugriff hast."
[AGGREGATION-FIRST, TicketPAY-Regeln, Replicate-Regeln, SharePoint-Regeln, alles aus dem heutigen Prompt OHNE Papierkram-Teil]
</werkzeug_prioritaet>
<anfrage_erkennung>
[aus heutigem Prompt]
</anfrage_erkennung>
vf-sonnet-buchhaltung.txt
{{include _base.txt}}
<werkzeug_prioritaet>
1. Buchhaltung, Belege, Rechnungen, Spesen, Mahnwesen → Papierkram (papierkram_*)
2. Events, Tickets, Verkaeufe → TicketPAY (ticketpay_*)
3. Emails, Kalender, SharePoint-Files, Excel-Inhalte → Microsoft 365 (sharepoint_*)
4. Bild-/Video-Generierung → Replicate (replicate_*)
5. Python-Berechnungen, PDF-Erzeugung, Diagramme → Code-Interpreter
6. Web-Suche → sharepoint_web_search / sharepoint_web_fetch_url
[AGGREGATION-FIRST, TicketPAY-Regeln, Papierkram-Regeln (komplett wie heute), Replicate-Regeln, SharePoint-Regeln]
</werkzeug_prioritaet>
<andre_buchhaltungs_kontext>
Andre ist Geschaeftsfuehrer + operativ aktuell Buchhaltung (Doppel-Hut, ueberlastet). Sein konkreter Workflow + die Software/Ordner die er nutzt:
**Buchhaltungs-Hauptsystem:** Papierkram.de (zugaenglich via papierkram_*-Tools). Hier landen alle Belege, Rechnungen, Vouchers, Projekte, Kunden, Zeiterfassung, Bank-Buchungen.
**Banking:** Sparkasse Online-Banking (TODO: genaue Software bei Andre erfragen — SFirm? StarMoney? oder Sparkassen-Web-Login?). Andre traegt Ueberweisungen aktuell HAENDISCH ein. Bank-Verbindung in Papierkram existiert ueber FinTS, kann via `papierkram_list_bank_transactions(bank_connection_id=...)` abgefragt werden.
**SharePoint-Ordner fuer Buchhaltung** (TODO: konkrete Pfade mit Andre/Christoph verifizieren, hier Vermutungen aus VF-Vault-Struktur):
- `https://vibefactorygbr.sharepoint.com/sites/intern/09_Belege/` — eingehende Belege, sortiert nach Jahr/Monat
- `https://vibefactorygbr.sharepoint.com/sites/intern/10_Buchhaltung/` — Auswertungen, USt-VA, Jahresabschluss-Vorbereitung
- `https://vibefactorygbr.sharepoint.com/sites/OwnCloud/` — gewachsene Dateiablage, auch hier liegen Belege/Rechnungen
**Typische Aufgaben die der Agent uebernehmen soll:**
1. **Eingehende Belege verbuchen** — User schickt ein PDF (oder verlinkt einen Belegg in SharePoint). Agent: extrahiert Lieferant, Datum, Brutto-Betrag, USt, Kategorie aus dem PDF (Code-Interpreter mit `pypdf` + Heuristiken). Legt Voucher in Papierkram an via `papierkram_create_voucher` + haengt PDF an via `papierkram_upload_voucher_document`. Bestaetigt mit Andre bevor Voucher final gespeichert wird (Status zuerst draft, Andre prueft).
2. **Ueberweisungen abgleichen** — Bank-Transaktion da, dazugehoeriger Voucher in Papierkram? Agent: `papierkram_list_bank_transactions` + `papierkram_list_vouchers` zusammenfuehren, fehlende Zuordnungen melden.
3. **Offene Posten** — `papierkram_offene_posten` direkt, plus Hinweis welche Kunden ueberfaellig sind und in welcher Phase (Mahnung 1, 2, 3 — Mahnwesen selbst geht nur in Papierkram-UI).
4. **Monatsabschluss** — `papierkram_monatsabschluss(year, month)` direkt, plus Vergleich Vormonat/Vorjahr in HTML-Report.
5. **USt-Voranmeldung-Vorbereitung** — Aggregate aus Papierkram ziehen, in vorbereitetes Excel-Template `10_Buchhaltung/USt-Vorbereitung_<jahr>.xlsx` schreiben (TODO: Template-Pfad mit Andre klaeren). Die eigentliche Voranmeldung macht Andre dann in ELSTER oder ueber Papierkram-UI.
6. **Belege-Quick-Search** — Andre sucht „die Rechnung von ECE letzten Monat" → `papierkram_list_invoices` mit Filter, plus SharePoint-Direktlink auf das Original-PDF wenn auffindbar.
**Was Andre haendisch macht (und was wir NICHT automatisieren):**
- Online-Banking-Login (TAN, Smart-Login mit S-pushTAN-App)
- Final-Freigabe von Ueberweisungen im Banking-Tool
- ELSTER-USt-Voranmeldung (Steuer-Software-Kontext, kein API-Zugriff)
- Mahnwesen-Versand (Papierkram-UI direkt, Mahn-Versand nicht ueber Agent)
**Token-Hygiene:** Andre ist Geschaeftsfuehrer + Mitgesellschafter. Bei Buchhaltungs-Anfragen direkt loslegen, kein „darf ich" — er hat Vollzugriff per definitionem. Aber bei kritischen Aktionen (Voucher final speichern, Ueberweisung anlegen falls jemals API-faehig, Rechnung versenden falls jemals via Agent) IMMER kurze Zusammenfassung + explizites Go abwarten — siehe `<mail_workflow>` (kein Senden) und analog fuer alle „raus aus dem Haus"-Aktionen.
</andre_buchhaltungs_kontext>
<anfrage_erkennung>
[aus heutigem Prompt]
</anfrage_erkennung>
TODO vor finalem Prompt-Build: mit Andre + Christoph einmal durchgehen und die Platzhalter (Sparkassen-Software-Name, exakte SharePoint-Pfade, Excel-Template-Pfad fuer USt) konkretisieren. Frageliste in fragen-an-andre unten.
build.py — Build + Deploy
Python-Script ~/source/apps/open-webui-vf/prompts/build.py:
#!/usr/bin/env python3
"""
Baut System-Prompts aus _base.txt + Variant-Files und pusht sie in Open WebUI.
Usage:
build.py --dry-run # nur ausgeben, kein Push
build.py --push # zusammenbauen + via Admin-API in Open WebUI Models pushen
build.py --push --model allgemein # nur ein bestimmtes Model pushen
"""
import os
import re
import sys
import subprocess
import argparse
import requests
from pathlib import Path
PROMPTS_DIR = Path(__file__).parent
MODELS = {
"allgemein": {
"owui_model_id": "vf-sonnet-allgemein",
"variant_file": "vf-sonnet-allgemein.txt",
},
"buchhaltung": {
"owui_model_id": "vf-sonnet-buchhaltung",
"variant_file": "vf-sonnet-buchhaltung.txt",
},
}
OWUI_BASE_URL = "https://vf-chat.agenticventures.de"
INCLUDE_PATTERN = re.compile(r"\{\{include (\S+)\}\}")
def build_prompt(variant_file: str) -> str:
"""Resolve {{include _base.txt}} markers and return full prompt string."""
text = (PROMPTS_DIR / variant_file).read_text(encoding="utf-8")
return INCLUDE_PATTERN.sub(
lambda m: (PROMPTS_DIR / m.group(1)).read_text(encoding="utf-8"),
text,
)
def get_admin_key() -> str:
"""Hole Admin-Key aus AWS Secrets Manager."""
out = subprocess.check_output([
"aws", "secretsmanager", "get-secret-value",
"--secret-id", "tmp/owui-admin-key",
"--profile", "av-production",
"--query", "SecretString", "--output", "text",
])
return out.decode().strip()
def push_model(model_id: str, prompt: str, admin_key: str) -> None:
"""Update das System-Prompt fuer ein Open WebUI Custom Model."""
resp = requests.post(
f"{OWUI_BASE_URL}/api/v1/models/update",
headers={"Authorization": f"Bearer {admin_key}"},
json={"id": model_id, "params": {"system": prompt}},
timeout=30,
)
resp.raise_for_status()
print(f"[ok] {model_id} updated ({len(prompt)} chars)")
def main() -> int:
parser = argparse.ArgumentParser()
parser.add_argument("--dry-run", action="store_true")
parser.add_argument("--push", action="store_true")
parser.add_argument("--model", choices=list(MODELS.keys()), default=None)
args = parser.parse_args()
targets = [args.model] if args.model else list(MODELS.keys())
admin_key = get_admin_key() if args.push else None
for name in targets:
cfg = MODELS[name]
prompt = build_prompt(cfg["variant_file"])
print(f"\n=== {name} ({len(prompt)} chars) ===")
if args.dry_run:
print(prompt[:500] + "...")
if args.push:
push_model(cfg["owui_model_id"], prompt, admin_key)
return 0
if __name__ == "__main__":
sys.exit(main())Open-WebUI-Admin-API-Endpoint fuer Model-Update: vor Push verifizieren (heute dokumentiert nur POST /api/v1/configs/tool_servers in der Capability-Doku — die korrekte Path-Form fuer Custom-Model-Update muss in der Open-WebUI-Source oder in der Live-API-Doku nachgeschlagen werden, bevor build.py zum ersten Mal --push macht).
Migrations-Schritte (Admin-Aufgaben in dieser Reihenfolge)
Phase A — Groups + Users (im Open WebUI Admin-Panel, ~10 Min)
- Login als Admin in
https://vf-chat.agenticventures.de - Admin Panel → Users → Groups → New Group:
- Name:
crew - Members: alle aktiven VF-User (Andre, Christoph, Julian, Felix, Johanna, Wladimir, Flemming)
- Name:
- Zweite Group:
buchhaltung- Members: Andre, Christoph
- Verifizieren: beide Groups erscheinen unter Admin Panel → Users → Groups, mit korrekter Member-Liste
Phase B — Custom Models anlegen (im Open WebUI Admin-Panel, ~15 Min)
- Admin Panel → Models → Create New Model:
- Model ID:
vf-sonnet-allgemein - Base Model:
claude-sonnet-4-6(oder das bestehende Bedrock-Profile) - System Prompt: leer lassen — wird per
build.py --pushbefuellt - Capabilities: function calling on, web search on, image input on, code interpreter on (alles was heute bei
vf-sonnetan ist) - Tools (
function_name_filter_list): Liste aus dieser Doku Abschnitt „Tool-Whitelistvf-sonnet-allgemein” eintragen - Access Control:
read→ Groupscrew+buchhaltung
- Model ID:
- Zweites Custom Model:
vf-sonnet-buchhaltung- Wie oben, aber Tools = allgemein-Liste + alle
papierkram_* - Access Control:
read→ Groupbuchhaltung
- Wie oben, aber Tools = allgemein-Liste + alle
- Default-Model pro User setzen: Admin Panel → Users → einzelner User → Default Model:
- Andre + Christoph →
vf-sonnet-buchhaltung - Alle anderen →
vf-sonnet-allgemein
- Andre + Christoph →
- Altes
vf-sonnetModel auf hidden setzen (nicht loeschen — Chat-Historien koennten darauf verlinken) — Admin Panel → Models → vf-sonnet → Visibility = hidden
Phase C — System-Prompts deployen (lokal von Marvins Maschine, ~5 Min)
cd ~/source/apps/open-webui-vf/prompts
# Existierenden vf-sonnet.txt in _base.txt + vf-sonnet-allgemein.txt + vf-sonnet-buchhaltung.txt aufteilen
# (initial einmal manuell, danach pflegbar in 3 Files)
# Dry-run zum Pruefen
python3 build.py --dry-run
# Wenn die zusammengebauten Prompts gut aussehen, deployen
python3 build.py --pushWenn build.py noch nicht existiert: in dieser Phase einmalig schreiben (~30 Min Arbeit), dann steht es fuer alle Folge-Updates.
Phase D — Verifikation (~10 Min)
- Test mit Andre-Account (oder Test-User in Group
buchhaltung):- Model-Picker zeigt beide Models —
vf-sonnet-allgemeinundvf-sonnet-buchhaltung - In
vf-sonnet-buchhaltung: „zeig mir die offenen Posten” → ruftpapierkram_offene_postenauf, funktioniert - In
vf-sonnet-allgemein: „zeig mir die offenen Posten” → Sonnet antwortet „dafuer bin ich nicht eingerichtet, wechsle aufvf-sonnet-buchhaltung”
- Model-Picker zeigt beide Models —
- Test mit Felix-Account (oder Test-User nur in Group
crew):- Model-Picker zeigt nur
vf-sonnet-allgemein - Felix kann
vf-sonnet-buchhaltungnicht ueber URL-Manipulation aufrufen (Open WebUI prueft Access-Control serverseitig — wenn doch, ist das ein Bug-Report an Open WebUI) - „Schick eine Mail an X mit Inhalt Y” → Sonnet legt Draft an, sagt „liegt im Postausgang als Entwurf, oeffne in Outlook und klicke Senden”
- Model-Picker zeigt nur
- Test send-Tool-Sperre in beiden Models:
- „Sende die Draft jetzt direkt” → Sonnet antwortet „ich kann nicht senden, das ist Absicht”
- Sicherheits-Doppelpruefung: in Open WebUI Admin → Functions/Tools → Liste durchgehen,
sharepoint_send_mailundsharepoint_send_draftundsharepoint_reply_messageduerfen in keinem Custom-Model in der Whitelist auftauchen
Praktikanten-Onboarding-Runbook
Wenn ein neuer Praktikant anfaengt — Schritte als Admin (Marvin oder Christoph), ~10 Min:
M365-Seite (5 Min)
- M365 Admin Center → Users → Add a user:
- Name:
<Vorname> <Nachname> - Username:
<vorname>@vibe-factory.de - License: Microsoft 365 Business Standard
- Initial password: generated, „force change at first login”
- Name:
- Exchange Online PowerShell oeffnen (oder das Skript aus Phase 2 der Auth-Haertung wiederverwenden):
Connect-ExchangeOnline -UserPrincipalName it-admin@VibeFactoryGbR.onmicrosoft.com Add-DistributionGroupMember -Identity "mcp-vf-hosted-allowed" -Member "<vorname>@vibe-factory.de" - (Optional) SharePoint-Site
internundOwnCloudZugriff geben — kommt durch Group-Membership in M365 vermutlich automatisch, aber pruefen.
Open-WebUI-Seite (3 Min)
vf-chat.agenticventures.de→ Admin Panel → Users → Add User:- Email:
<vorname>@vibe-factory.de(matched M365-Account) - Name:
<Vorname> <Nachname> - Role: User (nicht Admin)
- Initial password: generated
- Email:
- In Group
creweinfuegen — Admin Panel → Groups → crew → Add Member - Default Model:
vf-sonnet-allgemein(wird durch Group-Membership automatisch sichtbar, expliziter Default optional)
Onboarding-Mail an Praktikant (2 Min)
Vorlage (kann automatisiert werden, fuer jetzt manuell):
Hi <Vorname>,
dein Setup fuer die VibeFactory ist bereit:
1. M365-Login: <vorname>@vibe-factory.de
- Erst-Login auf https://www.office.com mit dem Passwort, das du gleich per separatem Kanal bekommst
- Beim ersten Login musst du das Passwort aendern + MFA einrichten
2. AI-Assistent („vf-chat"): https://vf-chat.agenticventures.de
- Gleicher Login wie oben (separater Account intern)
- Sprich mit dem Assistenten ueber Excel, SharePoint, Termine, Recherche, Designs (Bilder generieren)
- Buchhaltungs-Sachen kann er nicht — frag bei sowas Andre oder Christoph
Bei Fragen: Christoph (christoph@vibe-factory.de) ist der technische Ansprechpartner.
VibeFactory GmbH
Praktikant verlaesst das Team
Off-Boarding (nicht in diesem Plan ausformuliert, fuer Vollstaendigkeit):
- M365: User auf „Block sign-in” + Lizenz entziehen + aus Distribution Group entfernen
- Open WebUI: User auf disabled setzen (nicht loeschen, sonst verschwindet Chat-Historie)
- Wenn nach 30+ Tagen sicher dass keine Mail-/Doc-Wiederherstellung gebraucht wird: M365-User loeschen
Wenn Praktikanten-Onboarding >1x/Monat passiert: in Skill praktikant-onboarden packen mit automatischen PowerShell- + Open-WebUI-API-Calls. Heute: manuell.
Verifikations-Tests fuer Phase D
| Test | Wer | Erwartung |
|---|---|---|
| Felix-Login, Model-Picker oeffnen | Felix-Test-Account | nur vf-sonnet-allgemein sichtbar, kein vf-sonnet-buchhaltung |
| Andre-Login, Model-Picker oeffnen | Andre-Test-Account | beide Models sichtbar |
Felix versucht „zeig mir die Rechnungen” in allgemein | Felix | Sonnet sagt „dafuer nicht eingerichtet, frag Andre/Christoph” — KEIN papierkram-Tool-Call |
Andre versucht „Mail an X senden” in buchhaltung | Andre | Sonnet legt Draft an, sagt „liegt im Outlook-Entwurfs-Ordner, sende dort selbst” — KEIN send-Tool-Call |
Test-API direkt mit Felix-API-Key auf vf-sonnet-buchhaltung | Marvin via curl | 403 oder „model not accessible” — Open WebUI prueft Access-Control serverseitig |
| Tool-Liste in Open WebUI Admin pruefen | Marvin | sharepoint_send_mail, sharepoint_send_draft, sharepoint_reply_message in KEINEM Custom-Model in der Whitelist |
| Build-Script reproduzierbar | Marvin | build.py --dry-run gibt zwei vollstaendige Prompts aus, beide enthalten den _base-Inhalt |
Fragen an Andre vor Prompt-Finalisierung
Damit <andre_buchhaltungs_kontext> mit echten Werten gefuellt werden kann statt mit TODOs — kurzer Termin oder Telefonat mit Andre (besser: Andre + Christoph zusammen, ~20 Min):
- Welche Sparkassen-Software nutzt du fuer Banking? Sparkassen-Web-Login? SFirm? StarMoney? Etwas anderes? Auf welchem Geraet (PC, Browser, eigener Server)?
- Wie kommen Belege heute rein? Schicken Lieferanten an
rechnung@vibe-factory.de, anhello@, anandre@persoenlich, oder per Post-Scan? Welche dieser Wege ist heute der Haupt-Eingangs-Kanal? - Wo legst du die Belege ab? Konkrete SharePoint-Pfade. Sortier-Logik: nach Jahr/Monat, nach Lieferant, nach Projekt?
- USt-Voranmeldung — machst du das in Papierkram, ELSTER direkt, oder ueber Steuerberater? Gibt es ein Excel-Template das du als Vorbereitung pflegst? Wo liegt es?
- Mahnwesen — laeuft das ueber Papierkram-UI komplett (du klickst Mahnstufe an, Papierkram versendet)? Oder schreibst du Mahnungen manuell raus? Wann findet eine Mahnung statt — 14 Tage nach Faelligkeit, 30 Tage, ad-hoc?
- Was ist der laestigste Workflow-Schritt heute? (Andre’s eigene Worte) — z.B. „eingehende Belege ein-fuer-ein in Papierkram tippen”, „Bank-Transaktionen Beleg-Kandidaten zuordnen”, „Monatsabschluss-Aggregate zusammensuchen”. Das wird der erste Auto-Workflow-Kandidat.
Christoph kann den Termin mit Andre koordinieren (er ist AI-Steward). Output: Antworten in einem File andre-buchhaltungs-workflow-discovery.md neben diesem Plan, danach Prompt-Block aktualisieren.
Auto-Workflows als Folge-Projekt (separat zur Permission-Architektur)
Drei der Items oben sind keine Chat-Workflows sondern autonome Routinen die nebenher laufen und Andre die Drecksarbeit abnehmen. Gehoeren NICHT in diese Permission-Architektur, sondern in ein eigenes Projekt (z.B. intern/projekte/vf-buchhaltungs-routinen/):
- Belege-Auto-Voucher-Routine — Mailbox
rechnung@vibe-factory.destuendlich scannen → PDF erkennen → Voucher als Draft in Papierkram anlegen + PDF anhaengen + nach SharePoint kopieren → Mail labeln „bearbeitet” → Push-Notification an Andre „X neue Belege als Draft, bitte pruefen”. Pattern: Cron-Lambda imagents-platform-Stil. Bauzeit: ~2 Tage mitroutine-anlegen-Skill. - Bank-Buchung-Abgleich-Routine — taeglich (oder 2x pro Woche):
papierkram_list_bank_transactions(letzte 7 Tage) +papierkram_list_vouchers(offen) → Zuordnungs-Vorschlaege per Heuristik (Betrag exakt + IBAN match + Datum ±5 Tage). Output: HTML-Report mit Zuordnungs-Kandidaten, Andre klickt OK in Papierkram-UI. Bauzeit: ~1-2 Tage. - Monatsabschluss-Auto-Report — am 1. jedes Monats: Aggregate fuer Vormonat ziehen, HTML-Report generieren mit Vergleich Vormonat/Vorjahr/Jahresziel, in SharePoint ablegen, Push an Andre. Bauzeit: ~1 Tag.
Diese drei Routinen sind das eigentliche Produktivitaets-Geschenk fuer Andre — die Chat-Interaktion (vf-sonnet-buchhaltung) ist nur die „on-demand”-Schicht oben drauf.
Reihenfolge-Vorschlag fuer VF:
- Permission-Architektur (dieser Plan) ausrollen — Andre + Christoph kriegen
vf-sonnet-buchhaltungals Chat-Assistent - Andre-Workflow-Discovery durchziehen (20 Min Termin)
- Belege-Auto-Voucher-Routine bauen (groesster Hebel — Andre’s „laestigster Schritt”)
- Bank-Abgleich + Monatsabschluss-Report als 2. + 3. Welle
Offene Folgethemen
- Schicht 2 — MCP-User-Header-Scope-Lock:
mcp-vf-hostedliestX-OpenWebUI-User-Emailund erzwingt Mailbox-Scope auf User-Ebene (z.B. Andre kann nicht Felix’ Mailbox lesen, auch wenn der Agent es versuchen wuerde). Code-Patch ~1 Tag. Greift sobald Open-WebUI-UI-Layer bypassed werden koennte. - ApplicationAccessPolicy in Exchange Online: Allowlist
mcp-vf-hosted-allowedmit Andre, Christoph, Julian, Johanna, Felix, hello@, rechnung@. Schritte stehen in der vorherigen Konversation, noch nicht ausgefuehrt. Parallel zu Phase A-C dieser Doku abarbeiten. - hello@ in Shared Mailbox konvertieren: optional, spart ~12 EUR/Mo Lizenz. Keine Voraussetzung fuer Permission-Architektur.
- Praktikanten-Onboarding-Skill: wenn Frequenz >1x/Monat, manuelles Runbook in
intern/capabilities/skills/praktikant-onboarden/automatisieren (PowerShell + Open-WebUI-Admin-API + Vault-Eintrag). - Off-Boarding-Runbook: Spiegelung des On-Boarding-Schritts, hier nur skizziert.
papierkram_*Wildcard in Tool-Whitelist: pruefen ob Open WebUI Wildcards infunction_name_filter_listunterstuetzt. Falls ja: vereinfacht die Buchhaltungs-Whitelist-Pflege drastisch. Falls nein: alle ~70 Tool-Namen explizit eintragen und beim Hinzufuegen neuer Papierkram-Tools im MCP nachpflegen.
Aufwand-Schaetzung
| Phase | Wer | Aufwand |
|---|---|---|
| A — Groups + Users | Marvin als Admin | 10 Min |
| B — Custom Models anlegen | Marvin als Admin | 15 Min |
| C — System-Prompts deployen | Marvin (initial Build-Script schreiben) | 30 Min + 5 Min Deploy |
| D — Verifikation | Marvin | 10 Min |
| Gesamt | ~70 Min |
Plus die Prompt-Aufteilung von vf-sonnet.txt in _base.txt + zwei Variant-Files — separate Code-Editing-Session, ~30 Min.
Status + naechster Schritt
Status: draft. Ball bei Marvin — entscheiden ob Plan freigegeben ist, dann starte Phase A.
Naechster Schritt nach Freigabe: Phase A (Groups anlegen) live in Open WebUI ausfuehren, parallel Prompt-Aufteilung in ~/source/apps/open-webui-vf/prompts/ als separate /work-Session.