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 buchhaltung restricten (Andre + Christoph) — Group muss in Admin-UI angelegt werden, dann API-Call zum access_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

  1. Felix sieht keine Buchhaltungs-Tools. Andere Crew/Praktikanten auch nicht. Buchhaltung ist Andre + Christoph.
  2. Kein Agent sendet Mails raus. Drafts ja, Senden niemand. Human-in-the-Loop: User klickt in Outlook selbst auf „Senden”.
  3. Standard-Tools (SharePoint Read+Write Excel/PowerPoint/Files, Mail-Drafts, Web-Suche, Replicate-Bildgenerierung, TicketPAY, Code-Interpreter) sind fuer alle.
  4. Praktikanten-Onboarding muss easy sein — Standard-Workflow, kein Custom-Setup pro Person.
  5. 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:

ModelZweckTool-WhitelistAccess-ControlDefault fuer
vf-sonnet-allgemeinOffice-Assistent ohne Buchhaltungs-ZugriffSharePoint (alle inkl. Excel-Write, Drafts, Web-Suche), TicketPAY (alle), Replicate (alle), search_toolsGroup: crew UND buchhaltung (alle sehen es)Felix, Johanna, Julian, Wladimir, Flemming, Praktikanten
vf-sonnet-buchhaltungErweiterung um Papierkram-Toolswie allgemein + alle papierkram_* ToolsGroup: 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_invoice
  • papierkram_list_vouchers, papierkram_get_voucher, papierkram_create_voucher, papierkram_upload_voucher_document
  • papierkram_list_companies, papierkram_get_company, papierkram_create_company
  • papierkram_list_projects, papierkram_list_time_entries
  • papierkram_monatsabschluss, papierkram_offene_posten, papierkram_kunde_uebersicht
  • papierkram_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)

  1. Login als Admin in https://vf-chat.agenticventures.de
  2. Admin Panel → Users → Groups → New Group:
    • Name: crew
    • Members: alle aktiven VF-User (Andre, Christoph, Julian, Felix, Johanna, Wladimir, Flemming)
  3. Zweite Group: buchhaltung
    • Members: Andre, Christoph
  4. 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)

  1. 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 --push befuellt
    • Capabilities: function calling on, web search on, image input on, code interpreter on (alles was heute bei vf-sonnet an ist)
    • Tools (function_name_filter_list): Liste aus dieser Doku Abschnitt „Tool-Whitelist vf-sonnet-allgemein” eintragen
    • Access Control: read → Groups crew + buchhaltung
  2. Zweites Custom Model: vf-sonnet-buchhaltung
    • Wie oben, aber Tools = allgemein-Liste + alle papierkram_*
    • Access Control: read → Group buchhaltung
  3. Default-Model pro User setzen: Admin Panel → Users → einzelner User → Default Model:
    • Andre + Christoph → vf-sonnet-buchhaltung
    • Alle anderen → vf-sonnet-allgemein
  4. Altes vf-sonnet Model 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 --push

Wenn 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)

  1. Test mit Andre-Account (oder Test-User in Group buchhaltung):
    • Model-Picker zeigt beide Models — vf-sonnet-allgemein und vf-sonnet-buchhaltung
    • In vf-sonnet-buchhaltung: „zeig mir die offenen Posten” → ruft papierkram_offene_posten auf, funktioniert
    • In vf-sonnet-allgemein: „zeig mir die offenen Posten” → Sonnet antwortet „dafuer bin ich nicht eingerichtet, wechsle auf vf-sonnet-buchhaltung
  2. Test mit Felix-Account (oder Test-User nur in Group crew):
    • Model-Picker zeigt nur vf-sonnet-allgemein
    • Felix kann vf-sonnet-buchhaltung nicht 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”
  3. 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_mail und sharepoint_send_draft und sharepoint_reply_message duerfen 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)

  1. 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”
  2. 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"
  3. (Optional) SharePoint-Site intern und OwnCloud Zugriff geben — kommt durch Group-Membership in M365 vermutlich automatisch, aber pruefen.

Open-WebUI-Seite (3 Min)

  1. 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
  2. In Group crew einfuegen — Admin Panel → Groups → crew → Add Member
  3. 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):

  1. M365: User auf „Block sign-in” + Lizenz entziehen + aus Distribution Group entfernen
  2. Open WebUI: User auf disabled setzen (nicht loeschen, sonst verschwindet Chat-Historie)
  3. 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

TestWerErwartung
Felix-Login, Model-Picker oeffnenFelix-Test-Accountnur vf-sonnet-allgemein sichtbar, kein vf-sonnet-buchhaltung
Andre-Login, Model-Picker oeffnenAndre-Test-Accountbeide Models sichtbar
Felix versucht „zeig mir die Rechnungen” in allgemeinFelixSonnet sagt „dafuer nicht eingerichtet, frag Andre/Christoph” — KEIN papierkram-Tool-Call
Andre versucht „Mail an X senden” in buchhaltungAndreSonnet 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-buchhaltungMarvin via curl403 oder „model not accessible” — Open WebUI prueft Access-Control serverseitig
Tool-Liste in Open WebUI Admin pruefenMarvinsharepoint_send_mail, sharepoint_send_draft, sharepoint_reply_message in KEINEM Custom-Model in der Whitelist
Build-Script reproduzierbarMarvinbuild.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):

  1. Welche Sparkassen-Software nutzt du fuer Banking? Sparkassen-Web-Login? SFirm? StarMoney? Etwas anderes? Auf welchem Geraet (PC, Browser, eigener Server)?
  2. Wie kommen Belege heute rein? Schicken Lieferanten an rechnung@vibe-factory.de, an hello@, an andre@ persoenlich, oder per Post-Scan? Welche dieser Wege ist heute der Haupt-Eingangs-Kanal?
  3. Wo legst du die Belege ab? Konkrete SharePoint-Pfade. Sortier-Logik: nach Jahr/Monat, nach Lieferant, nach Projekt?
  4. 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?
  5. 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?
  6. 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/):

  1. Belege-Auto-Voucher-Routine — Mailbox rechnung@vibe-factory.de stuendlich 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 im agents-platform-Stil. Bauzeit: ~2 Tage mit routine-anlegen-Skill.
  2. 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.
  3. 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:

  1. Permission-Architektur (dieser Plan) ausrollen — Andre + Christoph kriegen vf-sonnet-buchhaltung als Chat-Assistent
  2. Andre-Workflow-Discovery durchziehen (20 Min Termin)
  3. Belege-Auto-Voucher-Routine bauen (groesster Hebel — Andre’s „laestigster Schritt”)
  4. Bank-Abgleich + Monatsabschluss-Report als 2. + 3. Welle

Offene Folgethemen

  • Schicht 2 — MCP-User-Header-Scope-Lock: mcp-vf-hosted liest X-OpenWebUI-User-Email und 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-allowed mit 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 in function_name_filter_list unterstuetzt. 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

PhaseWerAufwand
A — Groups + UsersMarvin als Admin10 Min
B — Custom Models anlegenMarvin als Admin15 Min
C — System-Prompts deployenMarvin (initial Build-Script schreiben)30 Min + 5 Min Deploy
D — VerifikationMarvin10 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.