Konzept: Agentische Desktop-Plattform „als-agentdesk"

1. Zielsetzung & Leitprinzipien

1.1 Auftrag in einem Satz

Die bestehende lokale Ollama-Weboberfläche (ms-ollama-ui) wird grundlegend neu gedacht: zu einer agentischen Multi-User-Desktop-Plattform für ein Software-Unternehmen, die die zentralen Funktionen der Claude-Desktop-App — Chat und mit klarem Schwerpunkt Cowork (agentisches Arbeiten an echten Dateien/Repos) — auf Basis lokaler Modelle via Ollama nachbildet.

1.2 Leitprinzipien

1. Lokalität & Datenschutz zuerst. Keine Firmendaten verlassen das Firmennetz. Alle Inferenz läuft auf firmeneigenen Apple-Silicon-Hosts; alle Dienste sind lokal (einzige Ausnahme: explizit freigegebene Connectors wie GitHub, §6). Das GDPR-Prinzip des Vorprojekts (keine CDN-/Font-Requests zur Laufzeit) gilt unverändert.
2. Agent vor Chat. Der Hauptanwendungsfall ist nicht das Gespräch, sondern das Arbeiten: Der Agent liest, schreibt und testet echten Code in echten Repos. Chat ist Grundfunktion, Cowork ist Produktkern.
3. Client leicht, Inferenz zentral. Die ThinkPad-Clients orchestrieren nur; die Modelle laufen auf dedizierten Mac Minis (bzw. Clustern). Strikte Client-/Inferenz-Trennung.
4. Rollen statt Freiheit für alle. Zwei Admins (Datenmanagement) haben Vollzugriff und bauen Agenten; Fachabteilungen erhalten kuratierte, rollengebundene Agenten mit bewusst beschnittenem Funktions- und Datenumfang.
5. Sicherheit ist Architektur, nicht Feature. Sandbox-Grenzen, Endpoint-Absicherung, Berechtigungs-Scoping und Audit sind von Anfang an Teil des Designs — nicht nachgerüstet.
6. Nicht überengineeren. Multi-User/Rollen sind gesetzt; alles Übrige bleibt so schlank, wie es die Enterprise-Anforderungen erlauben. Zielgröße initial: 2 Admins + 5–15 Nutzer, skalierbar.

1.3 Bewusste Reduktion gegenüber Claude Desktop

Nachgebaut werden Chat und Cowork (inkl. Datei-Zugriff, Sandbox, MCP-Connectors, Skills/Subagenten, geplante Tasks). Bewusst weggelassen (mit Begründung in §12): Browser-Steuerung, Computer-Use/Screenshot-Automation, Sprach-Ein-/Ausgabe, Mobile Apps, Artefakt-Rendering mit Live-Datenquellen, Plugin-Marketplace.

2. Gesamtarchitektur

2.1 Topologie-Überblick

2.2 Die drei Säulen

Begründung Steuerdienst auf dediziertem Server (Entscheidung): Verwaltung darf nicht an der Inferenz-Last eines Mac Mini hängen und muss auch erreichbar sein, wenn einzelne Inferenz-Hosts aus sind. Alle Steuerdienst-Komponenten (API, DB, Registry) sind CPU-Workloads; pgvector-Ähnlichkeitssuche für zentrale Wissensbasen läuft bei den erwarteten Datenmengen problemlos auf Server-CPUs. Einzige GPU-nahe Aufgabe wäre das Embedden zentraler Dokumente — das delegiert der Steuerdienst als Job an einen Inferenz-Host (Embedding-Modelle sind klein und schnell).

2.3 Datenflüsse (wer spricht mit wem)

1. Chat/Agent → Inferenz: Client-Main-Prozess → HTTPS → Caddy (TLS + API-Key) → Ollama. Streaming über SSE, re-attachbar (§8.3).
2. Client → Steuerdienst: Login/Token-Refresh, Agenten-/Skill-Sync, Policy-Abruf, Audit-Events (gebatcht), zentrale RAG-Abfragen.
3. Inferenz-Host → Steuerdienst: Metriken-Push (CPU/GPU/Unified-Memory), Health.
4. Niemals: Renderer → direkt ins Netz (alles über Main-Prozess-IPC); Client → fremder Inferenz-Host (Key-Scoping); Steuerdienst → Client-Dateien.

Das Muster des Vorprojekts („Client greift nie direkt auf Dienste zu, alles über eine API-Schicht") lebt hier als IPC-Grenze im Electron-Prozessmodell weiter: Der Renderer ist sandboxed und spricht ausschließlich über eine schmale, typisierte IPC-API (contextBridge) mit dem Main-Prozess; nur der Main-Prozess hat Netz-, Datei- und Prozess-Zugriff.

3. Stack-Empfehlung (begründet)

3.1 Gesetzt (nicht neu bewertet)

• Formfaktor: Electron-Desktop-App — derselbe Bauplan wie Claude Desktop, VS Code, Cursor, Slack. Reifster, risikoärmster Stack dieser App-Klasse.
• Renderer: Web-UI in TypeScript + React.
• Main-Prozess: Node/TypeScript als Agent-/Orchestrierungs-Core, saubere IPC-Trennung.
• Inferenz-Runtime: Ollama auf dedizierten Apple-Silicon-Hosts; Client-/Inferenz-Trennung.

3.2 Empfohlener Stack im Detail

3.3 Trade-off: Agent-Runtime TypeScript pur vs. Python-Sidecar

Empfehlung: rein TypeScript. Begründung:

• Die agentische Kernschleife (Prompt → Tool-Call → Tool-Ausführung → Ergebnis → nächster Turn) ist kein ML-Problem, sondern Orchestrierung — I/O, Prozesse, Streams. Genau dafür ist Node stark.
• MCP hat ein erstklassiges TypeScript-SDK; Ollama spricht HTTP (kein SDK-Zwang). Die Referenz-Agenten dieser Klasse (Claude Code, Codex CLI, Cline) sind TypeScript.
• Ein Prozessmodell, eine Toolchain, ein Packaging (electron-builder bündelt keinen Python-Interpreter) → kleinere App, weniger Update-/Signatur-Fläche, weniger Betriebsrisiko.
• Das „reichere Python-KI-Ökosystem" (Torch, Transformers, LangChain) wird nicht gebraucht: Training/Fine-Tuning ist out of scope, Inferenz macht Ollama, Embeddings macht Ollama.

Rückfalltür (bewusst offen gehalten): Sollte später ein Python-only-Baustein nötig werden (z.B. spezielle Dokument-Parser), wird er nicht als Sidecar-Dienst eingebaut, sondern als MCP-Server in Python angebunden — sauber über das Tool-Protokoll, ohne die Runtime zu verunreinigen.

3.4 Electron-Kehrseiten und Umgang damit

Alternative nur nachrichtlich — Tauri v2 (verworfen): schlanker (System-WebView statt Chromium, ~10 MB), sicherheitsfreundliches Capability-Modell, aber: Rust-Core (zweite Sprache im Team), jüngeres Ökosystem, WebView-Renderunterschiede zwischen Windows (WebView2) und macOS (WKWebView) kosten genau die UI-Konsistenz, die eine Claude-Desktop-artige Optik braucht. Die Entscheidung für Electron ist gesetzt.

4. Rechen-Topologie & Deployment

4.1 Endpoint-Abstraktion (Kernidee)

Der Client kennt einen konfigurierbaren Inferenz-Endpoint (Base-URL) pro Nutzer — bereitgestellt vom Steuerdienst bei der Provisionierung. Dahinter steht wahlweise:

Client-seitige Festlegung: Der Agent-Core spricht die OpenAI-kompatible Chat-Completions-API als primären Vertrag (Tool-Calling inklusive) und nutzt Ollama-native Endpunkte nur für Verwaltung (Pull/Liste/PS) und Embeddings. Begründung: Der OpenAI-Vertrag ist der kleinste gemeinsame Nenner über Ollama, exo und etwaige spätere Runtimes — der Client bleibt host-agnostisch.

Verifizierter Stand (Websuche, 2026):

• Ollama 0.19+ nutzt auf Apple Silicon ein MLX-Backend (Preview seit März 2026, Vollrelease angekündigt): ~1,6× schnellerer Prefill, ~2× schnellere Generierung; Preview verlangt ≥32 GB Unified Memory. → Mac-Hosts mit ≥32 GB einplanen, damit der MLX-Pfad greift.
• exo (exo-explore) ist aktiv gepflegt (Stand Juni 2026): MLX-basiert, Tensor-Parallelismus (~1,8× bei 2, ~3,2× bei 4 Geräten), RDMA über Thunderbolt 5 (macOS 26.2) für minimale Inter-Device-Latenz, vier API-Kompatibilitätsschichten (OpenAI, Ollama, u.a.).

4.2 Hardware-Empfehlung je Modellklasse

Faustregel: Modellgröße (Q4-Quantisierung) ≈ Parameter × 0,6 GB/Mrd. + Kontext-Overhead; das Unified Memory muss Modell + KV-Cache + OS (~8 GB Reserve) fassen.

Hinweis (verifiziert an apple.com/mac-mini/specs, Juli 2026): Die DRAM-Knappheit hat die bestellbare Palette spürbar eingeengt. Aktuell lieferbar: Mac Mini M4 mit 16/24 GB (die frühere 32-GB-Option ist gestrichen) und Mac Mini M4 Pro mit 24/48 GB (die frühere 64-GB-Option ist gestrichen). Der Mac Studio ist analog auf 96 GB begrenzt (128/256/512 GB gestrichen). Die M5-Generation ist beim Mac Mini noch nicht erschienen (M5/M5 Pro Mini für H2 2026 erwartet, während M5 in anderen Mac-Linien bereits ausgerollt ist). Konsequenz fürs Konzept: Das frühere Ziel „M4 Pro 64 GB" ist nicht mehr bestellbar → Standard heute: 1 Mac Mini M4 Pro 48 GB pro Power-User; wer >48 GB in einem Knoten braucht, geht auf Mac Studio (96 GB) oder exo-Cluster. Konkrete Kaufentscheidung zum Beschaffungszeitpunkt gegen die dann lieferbare Palette prüfen (M5-Mini kann die Lage bis H2 2026 verändern).

Empfehlung je Fall:

• Einzel-Mac (Standard): Ollama nativ mit MLX-Backend. Einfachster Betrieb, ein Dienst, Modell-Verwaltung über die Plattform (Pull/Delete wie im Vorprojekt).
• Cluster (Bedarfsfall): exo auf 2–4 Macs, Thunderbolt-5-Direktverbindung (RDMA), vom Admin als „Cluster-Endpoint" provisioniert. exo statt Eigenbau, weil Tensor-Parallelismus + Ollama-kompatible API fertig mitkommen. Halluzinations-Vorbehalt: exo entwickelt sich schnell; Feature-Stand (RDMA, API-Schichten) vor der Cluster-Beschaffung erneut gegen die offizielle Doku prüfen.

4.3 Absicherung des Inferenz-Endpoints

Problem (verifiziert): Ollama hat keine eingebaute Authentifizierung — mit OLLAMA_HOST=0.0.0.0 kann jeder im Netz Modelle nutzen. Das ist im Multi-User-Firmenkontext inakzeptabel.

Lösung: Auf jedem Inferenz-Host lauscht Ollama nur auf localhost; davor steht ein Caddy-Reverse-Proxy, der:

1. TLS terminiert (Zertifikat von der internen CA des Steuerdiensts; Caddy kann Zertifikate automatisiert beziehen/erneuern),
2. API-Keys pro Nutzer/Client prüft (Bearer-Token; ausgestellt und rotiert vom Steuerdienst),
3. nur die benötigten Pfade (/v1/…, /api/…) durchlässt und Requests mit Nutzer-ID fürs Audit logt.

*Verworfene Alternative:* mTLS statt API-Keys — kryptografisch stärker, aber Client-Zertifikats-Rollout auf ThinkPads erhöht die Betriebslast; API-Keys mit kurzer Laufzeit + TLS sind für ein Firmen-LAN/VPN angemessen. (Umstieg auf mTLS bleibt möglich, Caddy unterstützt beides.)

VPN: Mobiler Zugriff ausschließlich über das Firmen-VPN (Annahme: WireGuard o.ä. vorhanden — offener Punkt §13). Es gibt keinen Inferenz- oder Steuerdienst-Port, der über das LAN/VPN hinaus erreichbar ist.

4.4 Streaming & Latenz über VPN

Die re-attachbare Streaming-Architektur des Vorprojekts wird übernommen und verallgemeinert — sie ist die richtige Antwort auf VPN-Latenz und Verbindungsabrisse:

• Der Client startet Generierungen als Hintergrund-Jobs im Main-Prozess (analog IChatGenerationManager): Der Renderer abonniert einen lokalen Feed; reißt die HTTPS-Verbindung zum Mac ab, reconnectet der Main-Prozess mit Backoff und setzt den Stream fort, ohne dass UI-Zustand verloren geht.
• SSE mit Heartbeats (Kommentar-Frames alle ~15 s) verhindert, dass VPN-Gateways idle Verbindungen kappen; Timeouts sind großzügig (Token-Lücken bei großen Modellen), Abbruch läuft über explizites Cancel statt Timeout — exakt die Vorprojekt-Erfahrung (Timeout.InfiniteTimeSpan + CancellationToken).
• Agentische Läufe (Cowork) sind ohnehin job-basiert: Jeder Agent-Lauf hat eine ID, persistierten Zustand (Schritte, Tool-Calls, Diffs) und ist nach Reconnect/Neustart der App wieder anheftbar.

4.5 Datenhaltung — was liegt wo

Nicht-Ziel: Konversations-Sync zwischen Geräten eines Nutzers (v1). Ein Nutzer = ein ThinkPad; Sync wäre Aufwand ohne aktuellen Bedarf (§12).

5. Agentische Kernfähigkeit 1+2: Cowork-Workspace & Sandbox

5.1 Datei-/Ordnerzugriff (Workspace)

• Der Nutzer verbindet einen oder mehrere Workspace-Ordner (lokale Repos/Verzeichnisse). Der Agent erhält Datei-Tools: read, write, edit (Suchen/Ersetzen mit Kontextprüfung), glob, grep, ls — die bewährte Werkzeugpalette der Claude-Code-Klasse.
• Scoping: Tools arbeiten ausschließlich unterhalb der verbundenen Wurzeln (Pfad-Kanonisierung gegen ..-Ausbrüche und Symlink-Tricks); Schreiboperationen erzeugen Diffs, die im UI (Monaco-Diff-View) angezeigt werden.
• Genehmigungsmodell: Pro Workspace konfigurierbar — „Vorschlagsmodus" (jede Schreiboperation bestätigen), „Auto-Edit" (Schreiben frei, destruktive Aktionen bestätigen), „Frei" (nur Admin-Rolle). Abteilungs-Agenten laufen standardmäßig im Vorschlagsmodus mit read-only-Default.
• Git-Integration: Statuszeile, Diff-Ansicht, Commit-Vorschläge — aber keine autonomen Commits/Pushes (Vorprojekt-Regel wird Plattform-Policy; per Rolle deaktivierbar strengstens für Abteilungs-Agenten).

5.2 Code-Ausführung in der Sandbox

Entscheidung: Container-Isolation auf dem Client, nicht auf dem Mac-Host. Begründung: Code muss neben den Dateien laufen (Builds/Tests brauchen den Workspace); ThinkPads sind für KI-Inferenz zu schwach, aber Builds/Tests sind normale Entwickler-Workloads. Den Workspace zum Mac zu spiegeln hieße Datei-Sync-Komplexität + Latenz ohne Sicherheitsgewinn.

Technik (Windows-Client):

• Docker mit WSL2-Backend als Isolationsschicht: Der Agent führt Befehle in einem Sandbox-Container aus — non-root, Workspace als Bind-Mount (auf explizit verbundene Ordner begrenzt), kein Netz per Default (Egress opt-in je Lauf/Policy, z.B. für npm install mit Registry-Allowlist), CPU-/RAM-Limits, strikte Timeouts pro Kommando.
• Pro Projekttyp vorbereitete Sandbox-Profile (Node, .NET, Python, …) als versionierte Images aus einer internen Registry (Steuerdienst hostet sie).
• Terminal-Transparenz: Alles, was der Agent ausführt, ist live im xterm.js-Panel sichtbar; der Nutzer kann eingreifen/abbrechen.

Bewusst beobachtete Alternative: Microsoft Execution Containers (MXC) — auf der Build 2026 vorgestellte, OS-erzwungene Sandbox für KI-Agenten auf Windows/WSL (Hypervisor-gestützt, wenig Overhead). Vielversprechend als spätere native Option, aber zu jung für eine tragende Architekturentscheidung (Halluzinations-/Verfügbarkeitsvorbehalt; vor Einsatz gegen offizielle Microsoft-Doku verifizieren). Die Sandbox liegt deshalb hinter einem eigenen Interface (SandboxProvider), sodass Docker/WSL2 später durch MXC ersetzbar ist, ohne Agent-Code anzufassen.

Sicherheitsgrenzen (zusammengefasst):

6. Agentische Kernfähigkeit 3: MCP-Connectors / Tools

• Protokoll: MCP mit offiziellem TypeScript-SDK. Lokale Server via stdio (vom Main-Prozess als Child-Prozesse verwaltet), zentrale/entfernte via Streamable HTTP (Spec-Stand 2026 verifiziert; die 2026-07-Spec macht Remote-MCP hinter normalen Load-Balancern einfacher — für den Steuerdienst relevant).
• Priorisierte Connectors (Marc, geklärt): GitHub (Repos, PRs, Issues), M365/E-Mail/Dateiablagen (Microsoft Graph: Outlook, SharePoint/OneDrive) und Snowflake (Data-Warehouse-Abfragen für Fach-/Datenrollen). Alle drei existieren als gepflegte MCP-Server — vor Integration Version/Feature-Stand prüfen.
• Kuratierter Katalog statt Wildwuchs: Der Admin pflegt im Steuerdienst einen Connector-Katalog (geprüfte MCP-Server, gepinnte Versionen, Konfig-Vorlagen). Nutzer/Agenten können nur Katalog-Einträge nutzen, die ihre Rolle erlaubt. Kein freies „installiere beliebigen MCP-Server" für Nicht-Admins — das ist die zentrale Supply-Chain-Verteidigung.
• Credential-Handling: Connector-Zugänge (GitHub-Token, Graph-OAuth, Snowflake-Key) liegen client-seitig in der OS-Keychain (safeStorage); OAuth-Flows laufen über den System-Browser. Abteilungs-Agenten können alternativ zentral verwaltete Service-Zugänge nutzen (vom Admin hinterlegt, aufs Nötigste berechtigt), damit Fachnutzer keine eigenen Tokens verwalten müssen.
• Tool-Gating im Agent-Lauf: Jeder Tool-Call wird gegen die Rollen-Policy geprüft (Allowlist je Agent), sensible Aktionen (Mail senden, PR erstellen, Daten schreiben) erfordern konfigurierbar eine UI-Bestätigung; alle Calls landen im Audit-Log.

7. Agentische Kernfähigkeit 4: Skills, Subagenten & geplante Tasks

7.1 Skills

• Format: Markdown-basierte Skill-Pakete (SKILL.md + optionale Skripte/Assets) — bewusst das etablierte, menschenlesbare Format der Claude-Klasse: versionierbar, reviewbar, ohne Code-Deployment änderbar.
• Verteilung: Skills liegen in der Skill-Registry des Steuerdiensts (versioniert, signiert). Admins kuratieren; Rollen bekommen Skill-Sets zugewiesen; Clients synchronisieren read-only. Power-User (Admin-Rolle) können lokale Entwurfs-Skills anlegen und in die Registry promoten.

7.2 Subagenten

• Der Haupt-Agent kann Subagenten mit eigenem Kontextfenster, eingeschränktem Tool-Set und eigenem Systemprompt starten (z.B. „Explorer" read-only für Codebase-Recherche, „Tester" nur Sandbox+Read). Subagenten erben höchstens die Rechte des Elternlaufs — nie mehr (Prinzip der Rechte-Verjüngung).
• Technisch: gleiche Agent-Loop, eigener Job im Main-Prozess, Ergebnis fließt als Tool-Resultat zurück. Parallelität begrenzt (Konfig), da jeder Subagent Inferenz-Last auf dem Mac erzeugt.

7.3 Geplante / automatisierte Tasks

• Nutzer (rollenabhängig) planen wiederkehrende Agent-Läufe („jeden Morgen Issue-Digest", „nightly Testlauf mit Bericht"). Ausführung client-seitig durch den Main-Prozess (App muss laufen; v1-Vereinfachung) — kein serverseitiger Agent-Runner in v1 (§12).

7.4 Agenten-Definition & Provisionierung (Bindeglied zum Rollenmodell)

Eine Agenten-Definition ist ein versioniertes, vom Steuerdienst signiertes Manifest:

# agent-manifest (Beispiel, vereinfacht)
id: dept-sales-reporting
version: 3
model: { endpoint: "assigned", name: "qwen3:32b", params: { temperature: 0.2 } }
system_prompt: …
tools:
  files: { mode: read_only, roots: ["%USERPROFILE%/Berichte"] }
  sandbox: { enabled: false }
  mcp: [ "m365-mail:read", "snowflake:query_readonly" ]
skills: [ "report-format@2", "snowflake-sales-queries@1" ]
knowledge_bases: [ "kb-sales-handbuch" ]
approvals: { mail_send: always_ask }
audit: full

Der Admin „schneidet" Agenten zu (Modell, Tools, Skills, Wissensbasen, Genehmigungen), weist sie Rollen zu; Clients laden beim Login die Manifeste ihrer Rolle. Signaturprüfung im Client verhindert manipulierte Manifeste; Abteilungs-Clients zeigen ausschließlich provisionierte Agenten (keine freie Agenten-Erstellung).

8. Nutzer-, Rollen- & Berechtigungsmodell

8.1 Rollen

Rollen sind additiv erweiterbar (skalierbar auf mehr Abteilungen); Rechte sind als Policies modelliert (Ressource × Aktion × Scope), Rollen bündeln Policies — kein hartkodiertes Rollen-Enum.

8.2 Identität & Authentifizierung

• Eigene Nutzerverwaltung im Steuerdienst, synchronisiert mit LDAP (geklärt): LDAP ist Quelle für Identitäten/Gruppen (Sync-Job mappt LDAP-Gruppen → Plattform-Rollen); die Plattform bleibt auch bei LDAP-Ausfall arbeitsfähig (lokaler Passwort-/Token-Cache mit Ablauf).
• Token-Fluss: Login im Client → Steuerdienst stellt kurzlebiges Access-Token + Refresh-Token aus (OIDC-artig); das Access-Token trägt Rolle + zugewiesenen Inferenz-Endpoint + Key-Referenz. Inferenz-API-Keys werden vom Steuerdienst ausgestellt und rotiert.
• Offline-Verhalten: Ohne Steuerdienst-Verbindung arbeitet der Client mit gecachten Policies/Manifests weiter (Ablauffrist, z.B. 72 h), danach degradiert er auf read-only-Chat gegen den Inferenz-Host — bewusster Trade-off zwischen Verfügbarkeit und Kontrolle.

8.3 Ressourcen-Zuweisung & Provisionierung (Ablauf)

1. Admin legt Nutzer an (bzw. LDAP-Sync liefert ihn) und weist Rolle + Inferenz-Ressource zu (Mac Mini X oder Cluster Y → Base-URL + Key).
2. Steuerdienst provisioniert den Host (erwartete Modelle pullen — via Ollama-API skriptbar; Caddy-Key eintragen).
3. Nutzer installiert die Desktop-App (interner Installer-Link), meldet sich an; die App zieht Endpoint, Agenten-Manifeste, Skills, Policies.
4. Erster Lauf ist geführt (Bootstrap-Erbe des Vorprojekts): Health-Checks Endpoint/Steuerdienst/Sandbox, klare Reparatur-Hinweise je Komponente.

8.4 Auditierbarkeit

Append-only-Audit im Steuerdienst: Logins, Agent-Läufe (Start/Ende/Modell), Tool-Calls (inkl. MCP-Ziel, ohne sensible Payload-Inhalte per Default — konfigurierbar), Datei-Schreiboperationen (Pfad+Hash, nicht Inhalt), Genehmigungen/Ablehnungen, Provisionierungs-Änderungen (wer hat welchem Agenten welches Recht gegeben). Einsicht nur Admin-Rolle; Aufbewahrung konfigurierbar.

9. Chat (Grundfunktion, bewusst schlank)

• Streaming-Chat mit Verlauf, mehreren Konversationen, Systemprompt, Markdown-Rendering (XSS-sicher — Markdig-Erfahrung übertragen: HTML im Modell-Output escapen), Code-Highlighting lokal gebündelt, Stop, Modellwahl (rollenabhängig).
• Konversationsgebundenes RAG wie im Vorprojekt (Upload im Composer, Ingest-Pipeline: Extraktion → Chunking → Ollama-Embeddings → sqlite-vec; Quellen als strukturierte Events) — die komplette P4-Erfahrung wird übernommen, nur der Vektorspeicher wechselt (§3.2).
• Zentrale Wissensbasen: Abteilungs-Agenten können zusätzlich zentral kuratierte KBs abfragen (Retrieval-Call an den Steuerdienst, pgvector) — der Unterschied lokal/zentral ist für den Nutzer unsichtbar, Quellen bleiben ausgewiesen.
• Web-Suche: optional per lokalem SearXNG (auf dem Steuerdienst-Server als Container) — Vorprojekt-Muster inkl. Query-Rewriting und Bedarfs-Gate; als MCP-Tool angebunden statt fest verdrahtet.

10. Design-Konzept (Claude-Desktop-Anmutung)

• Grundhaltung: ruhig, großzügig, viel Weißraum, runde Ecken (Radius-Skala ~8/12/16 px), klare Typografie (System-Font-Stack; keine externen Fonts — GDPR), weiche Trennlinien, zurückhaltende Schatten.
• Farbwelt: warme Neutraltöne (Papier-/Cremeweiß im Light, tiefes Warmgrau im Dark) mit einem Akzent in gedecktem Terracotta/Koralle für Primäraktionen und Agent-Aktivität; Statusfarben sparsam (Grün/Rot/Gelb für Health/Diff/Warnung). Das „exo × Claude"-Gespür des Vorprojekts fließt ins Monitoring (kompakte Kacheln, klare Zahlen) ein.
• Dark/Light mit System-Default, persistiert; Design-Tokens als CSS Custom Properties (Farben, Abstände, Radien, Schatten) — pro Theme werden nur Variablen umgeschaltet (bewährtes Vorprojekt-Muster, FR-UI-5-Erbe).
• Layout: linke, einklappbare Sidebar (Konversationen/Agenten/Bereiche), Hauptfläche Chat/Cowork, rechtes Kontext-Panel (Dateien, Diffs, Terminal, Tool-Aktivität). Cowork-Ansicht: Chat links, Arbeitsbereich (Monaco-Diff / xterm.js / Datei-Baum) rechts.
• Icons: als eingebettete SVGs (Lucide oder Material), keine Font-/CDN-Requests.

11. Datenmodell (logisch, verbindlich für Teil B)

Steuerdienst (PostgreSQL):

users(id, ldap_dn, name, email, status, created_at)
roles(id, name, description)
user_roles(user_id, role_id)
policies(id, resource, action, scope_json)          -- z.B. mcp:m365-mail, action:read
role_policies(role_id, policy_id)
inference_endpoints(id, base_url, kind[ollama|exo], hw_notes, status)
endpoint_assignments(user_id, endpoint_id, api_key_ref, assigned_by, assigned_at)
agents(id, name, version, manifest_yaml, signature, status[draft|published|retired], created_by)
role_agents(role_id, agent_id)
skills(id, name, version, package_ref, signature, status)
role_skills(role_id, skill_id)
knowledge_bases(id, name, embedding_model, dim)
kb_documents(id, kb_id, filename, status, …)
kb_chunks(id, document_id, content, embedding vector(dim), page)
role_knowledge_bases(role_id, kb_id)
audit_events(id, ts, user_id, kind, payload_json)   -- append-only
host_metrics(ts, endpoint_id, cpu, gpu, umem_used, umem_total, …)  -- Zeitreihe, Retention

Client (SQLite):

conversations(id, title, agent_id, model, system_prompt, created_at, updated_at)
messages(id, conversation_id, role, content, token_count, duration_ms, sources_json, created_at)
agent_runs(id, conversation_id, status, started_at, finished_at, summary)
run_steps(id, run_id, seq, kind[tool_call|output|approval], payload_json)
documents(id, conversation_id, filename, mime, status, …)     -- konversationsgebunden (Vorprojekt-Muster)
chunks(id, document_id, chunk_index, content, page)           -- + sqlite-vec-Tabelle für Embeddings
settings(key, value)                                          -- pro Gerät/Nutzer
cached_manifests(agent_id, version, manifest_yaml, signature, fetched_at)
pending_audit(id, ts, kind, payload_json)                     -- Offline-Puffer

12. Übernommen vs. neu gedacht vs. weggelassen

12.1 Aus ms-ollama-ui übernommen (Erfahrungsschatz)

12.2 Bewusst neu gedacht

12.3 Bewusst weggelassen (Scope-Grenzen)

13. Monitoring (Zielwechsel: Apple Silicon)

• Gemessen wird der Inferenz-Host, nicht der ThinkPad (Vorprojekt-Prinzip „Metriken zeigen den Host"): CPU-Last, GPU-Last (Metal), Unified-Memory-Belegung, Leistungsaufnahme (best-effort), geladene Modelle (/api/ps).
• Erfassung: schlanker Metrics-Agent auf jedem Mac (launchd-Dienst), Quelle powermetrics/sysctl bzw. eine gepflegte CLI wie macmon (sudoless Apple-Silicon-Metriken) — vor Implementierung Feature-Stand verifizieren (junges Tool). Push an den Steuerdienst; Retention als Zeitreihe.
• Cluster-Sicht: exo-Cluster erscheinen als Gruppe (je Node + Aggregat) — die exo-Dashboard-Anmutung des Vorprojekt-Designs passt hier wörtlich.
• Anzeige: Monitoring-Bereich in der Desktop-App (Admin: alle Hosts; Nutzer: nur der eigene). Graceful Degradation wie gehabt: fehlende Sensoren ⇒ „n/a", nie Crash.

14. Sicherheits-Gesamtbild (Kurzreferenz)

15. Offene Punkte

Annahmen (bitte bestätigen oder korrigieren)

Offene Fragen

Ende Teil A. Testbare Anforderungen: ANFORDERUNGEN.md. Phasenplan: ROADMAP.md. Web-Präsentation: docs/index.html.