Anforderungen: als-agentdesk
Dieses Dokument konkretisiert das Konzept zu testbaren Anforderungen. Jede Anforderung hat eine eindeutige ID, einen klaren Scope und Akzeptanzkriterien (AK). Bei Konflikten zwischen diesem Dokument und dem Konzept gilt dieses Dokument. Die Phasenzuordnung steht in ROADMAP.md.
Rollen-Kürzel in AK: ADM = Admin/Datenmanagement, DEV = Entwickler-Rolle, DEP = Fach-/Abteilungsrolle.
1. Technische Rahmenanforderungen (TR)
| ID | Anforderung | AK |
|---|---|---|
| TR-1 | Client als Electron-App (Renderer: React + TypeScript; Main: Node/TypeScript-Agent-Core), gebaut mit Vite + electron-builder. | App baut reproduzierbar für Windows (NSIS); Renderer läuft mit contextIsolation: true, nodeIntegration: false, sandboxed. |
| TR-2 | Strikte IPC-Grenze: Renderer hat keinerlei direkten Netz-/Datei-/Prozess-Zugriff; alles läuft über eine schmale, typisierte contextBridge-API des Main-Prozesses. | Statischer Check/Review: kein remote, keine Node-APIs im Renderer; jede IPC-Methode ist im Shared-Contract typisiert. |
| TR-3 | Inferenz host-agnostisch: Der Agent-Core spricht die OpenAI-kompatible Chat-Completions-API (inkl. Tool-Calling) als Primärvertrag; Ollama-native Endpunkte nur für Verwaltung (/api/tags, /api/pull, /api/ps, /api/embed). Base-URL pro Nutzer konfigurierbar. | Wechsel der Base-URL von Einzel-Mac (Ollama) auf exo-Cluster erfordert keine Client-Codeänderung; Chat + Tool-Calls funktionieren gegen beide. |
| TR-4 | Kein unauthentifizierter Inferenz-Zugriff: Ollama lauscht nur auf localhost; davor Reverse-Proxy (Caddy) mit TLS + Bearer-API-Key je Nutzer + Pfad-Allowlist. | Request ohne/mit falschem Key ⇒ 401; Ollama-Port 11434 ist von außen nicht erreichbar (Portscan); TLS-Zertifikat von interner CA gültig. |
| TR-5 | Streaming über SSE, re-attachbar: Generierungen/Agent-Läufe laufen als Jobs im Main-Prozess; Renderer abonniert lokal; Netzabriss zum Inferenz-Host ⇒ automatischer Reconnect mit Backoff; Heartbeats (~15 s) halten VPN-Verbindungen offen. | Trennen/Wiederverbinden des VPN während einer laufenden Antwort: Stream setzt fort oder Lauf-Ergebnis erscheint nach Reconnect; kein UI-Datenverlust; App-Neustart zeigt laufenden/abgeschlossenen Lauf korrekt. |
| TR-6 | Persistenz Client: SQLite (better-sqlite3) + sqlite-vec; Schema gemäß Konzept §11; Migrationen versioniert. | App startet gegen leere DB und migriert selbst; Downgrade-Schutz (Schema-Version). |
| TR-7 | Persistenz Steuerdienst: PostgreSQL 17 + pgvector; Schema gemäß Konzept §11; Betrieb via Docker Compose. | compose up erzeugt lauffähigen Dienst inkl. Migrationen; Vektor-Suche über HNSW-Index funktioniert. |
| TR-8 | Robuste Fehlerbehandlung: Nicht erreichbare Dienste (Inferenz-Host, Steuerdienst, Sandbox, MCP-Server) führen zu klaren, benutzerverständlichen Meldungen und degradiertem Betrieb — nie zu Crash oder Silent-Fail. | Jeder externe Ausfall hat einen definierten UI-Zustand (Banner/Status) und einen Wiederholungspfad. |
| TR-9 | Konfiguration über Konfigurationsdateien/ENV; keine hartkodierten URLs/Ports/Secrets. Secrets im Client via safeStorage (OS-Keychain), auf dem Server via ENV/Secret-Store. | Code-Review: keine Secrets/URLs im Code; Secret-Werte erscheinen in keinem Log. |
| TR-10 | Auto-Update: electron-updater gegen internen HTTPS-Update-Feed (generic provider) auf dem Steuerdienst; Windows-Builds Authenticode-signiert. | Neue Version im Feed ⇒ Client updatet nach Bestätigung; Signaturprüfung schlägt bei manipuliertem Artefakt fehl. |
| TR-11 | Geteilte Contracts: IPC-, REST- und Manifest-Schemata liegen als versionierte TypeScript-Typen (z.B. zod-Schemas) in einem Shared-Package zwischen Client und Steuerdienst. | Breaking Change im Schema bricht den Build beider Seiten (Typprüfung), nicht erst die Laufzeit. |
| TR-12 | Cross-Platform-Fähigkeit: Code bleibt auf Windows + macOS + Linux baubar (CI-Matrix); primäres Auslieferungs-OS v1 ist Windows. | CI baut alle drei Plattformen grün; OS-spezifisches liegt hinter Interfaces (z.B. SandboxProvider). |
2. Funktionale Anforderungen (FR)
2.1 Chat (FR-CHAT)
| ID | Anforderung | AK |
|---|---|---|
| FR-CHAT-1 | Konversationen anlegen, umbenennen, löschen; Seitenliste mit Umschalten; Verlauf persistent (lokal, SQLite). | Wechsel lädt Verlauf; Löschen kaskadiert Nachrichten/Dokumente; Daten liegen ausschließlich client-seitig. |
| FR-CHAT-2 | Nachricht senden, Antwort als Token-Stream; Generierung überlebt Navigation, App-Reload und Netzabriss (TR-5). | Token erscheinen inkrementell; nach Reload hängt sich das UI an den laufenden Job an; Teiltext bleibt bei Abbruch erhalten. |
| FR-CHAT-3 | Verlauf als Kontext; optionaler System-Prompt je Konversation; Modellwahl im Header (rollenabhängig: DEP nur Manifest-Modell). | Modell antwortet kontextbezogen; DEP sieht keine Modellauswahl; ADM/DEV können umschalten (persistiert). |
| FR-CHAT-4 | Markdown-Rendering inkl. Code-Blöcken mit Syntax-Highlighting; XSS-sicher (HTML im Modell-Output wird escaped); Highlighting-Assets lokal gebündelt. | Kein rohes Markdown sichtbar; Injection-Testfall (HTML/Script im Output) wird escaped; keine externen Requests beim Rendern. |
| FR-CHAT-5 | Laufende Antwort stoppen. | Stop bricht Stream + Inferenz-Request ab; Teiltext persistiert. |
| FR-CHAT-6 | Konversationsgebundenes RAG: Datei-Upload (PDF, DOCX, TXT, MD) im Composer; Ingest asynchron (Extraktion → Chunking → Embedding via Ollama /api/embed → sqlite-vec); Status sichtbar; Retrieval nur über Dokumente der aktiven Konversation; Quellenangabe strukturiert. | Status pending→processing→ready/failed sichtbar; Antworten referenzieren Dokument+Seite/Chunk; Anhänge anderer Konversationen fließen nie ein; Löschen der Konversation entfernt Dokumente+Chunks+Datei-Blobs. |
| FR-CHAT-7 | Zentrale Wissensbasen: Dem Agenten zugewiesene KBs (Manifest) werden beim Retrieval zusätzlich abgefragt (Steuerdienst, pgvector); Quellen kennzeichnen die KB. | DEP-Agent mit KB beantwortet KB-Fragen mit Quellenangabe; ohne KB-Zuweisung keine zentrale Abfrage (Netz-Log). |
| FR-CHAT-8 | Web-Suche optional über lokales SearXNG (Container auf dem Steuerdienst-Server), angebunden als MCP-Tool; Bedarfs-Gate + Query-Rewriting (Vorprojekt-Muster); graceful Fallback bei Ausfall. | Smalltalk löst keine Suche aus; Quellen-Links klickbar; SearXNG aus ⇒ Hinweis, Chat funktioniert weiter. |
2.2 Cowork / Agent-Läufe (FR-CW)
| ID | Anforderung | AK |
|---|---|---|
| FR-CW-1 | Agent-Loop: Der Agent plant, ruft Tools auf (Dateien, Sandbox, MCP), verarbeitet Ergebnisse und iteriert bis Abschluss/Abbruch; jeder Lauf ist ein persistierter Job mit Schritten (Tool-Calls, Outputs, Genehmigungen). | Lauf-Historie zeigt jeden Schritt nachvollziehbar; Reload/Reconnect stellt den Lauf-Zustand wieder her (TR-5). |
| FR-CW-2 | Tool-Aktivität live sichtbar: Aktueller Schritt, Tool-Name, Ziel (Datei/Kommando/Connector) werden während des Laufs angezeigt. | Nutzer sieht in Echtzeit, was der Agent tut; kein „Blackbox"-Lauf. |
| FR-CW-3 | Genehmigungs-Gates: Aktionen der Kategorien Schreiben/Ausführen/Extern (Mail, PR, DB-Write) erfordern gemäß Agent-Manifest Bestätigung im UI; Entscheidung wird im Lauf und Audit protokolliert. | Manifest always_ask ⇒ Modal vor Aktion; Ablehnung bricht nur die Aktion ab, nicht den Lauf; Audit-Event vorhanden. |
| FR-CW-4 | Abbruch/Kill-Switch: Ein Lauf ist jederzeit abbrechbar; laufende Sandbox-Prozesse werden beendet. | Abbruch ⇒ Prozesse in <5 s beendet; Workspace bleibt in konsistentem Zustand (kein halber Write). |
| FR-CW-5 | Subagenten: Der Agent kann Subagenten mit eigenem Kontext, reduziertem Tool-Set und eigenem Systemprompt starten; Rechte höchstens die des Elternlaufs; Parallelität konfigurierbar begrenzt. | Subagent mit read-only-Set kann nicht schreiben (Testfall); Ergebnis fließt als Schritt in den Elternlauf; Limit wird durchgesetzt. |
| FR-CW-6 | Geplante Tasks (client-seitig): Wiederkehrende/einmalige Agent-Läufe planbar (Cron-artig); Ausführung durch den Main-Prozess, wenn die App läuft; verpasste Läufe werden gemeldet, nicht still nachgeholt. | Geplanter Lauf startet zur Zeit X; App zu ⇒ beim nächsten Start Hinweis „verpasst". |
| FR-CW-7 | Kontext-Management: Lange Läufe komprimieren älteren Verlauf (Zusammenfassung), statt am Kontextfenster zu scheitern; Modell-Kontextlänge (num_ctx-Äquivalent) pro Agent konfigurierbar. | Lauf mit >Kontextfenster Historie läuft weiter; Zusammenfassungsschritt im Lauf sichtbar. |
2.3 Datei-Zugriff / Workspace (FR-FILE)
| ID | Anforderung | AK |
|---|---|---|
| FR-FILE-1 | Workspace-Ordner verbinden/trennen (mehrere möglich); Agent-Datei-Tools (read, write, edit, glob, grep, ls) arbeiten ausschließlich unterhalb verbundener Wurzeln. | Pfad-Traversal-Tests (.., Symlinks, absolute Pfade) scheitern; Zugriff außerhalb ⇒ Tool-Fehler + Audit-Event. |
| FR-FILE-2 | Schreiboperationen erzeugen Diffs (Monaco-Diff-View); Genehmigungsmodus pro Workspace: Vorschlagsmodus / Auto-Edit / Frei (Frei nur ADM). | Diff vor Anwendung sichtbar im Vorschlagsmodus; DEP-Agenten sind auf Manifest-Modus (Default read-only/Vorschlag) begrenzt. |
| FR-FILE-3 | Rollen-Scoping: Für DEP-Agenten sind erlaubte Wurzeln + Modus (read-only/write) im Manifest fixiert; Nutzer können sie nicht erweitern. | DEP-Client bietet keine Ordnerwahl außerhalb der Manifest-Roots an; Manipulationsversuch (editierte Lokal-Config) scheitert an Signaturprüfung. |
| FR-FILE-4 | Git-Bewusstsein: Statuszeile (Branch, Änderungen), Diff-Ansicht gegen HEAD, Commit-Vorschläge; keine autonomen Commits/Pushes durch den Agenten. | Agent formuliert Commit-Message als Vorschlag; git commit/push erscheinen nie in Sandbox-Historie ohne explizite Nutzeraktion. |
2.4 Sandbox / Code-Ausführung (FR-SBX)
| ID | Anforderung | AK |
|---|---|---|
| FR-SBX-1 | Code-/Kommando-Ausführung ausschließlich im Sandbox-Container (Docker/WSL2 hinter SandboxProvider-Interface): non-root, Workspace-Bind-Mounts nur für verbundene Ordner, CPU-/RAM-Limits, Timeout je Kommando. | Kommando läuft als non-root (id-Test); Zugriff auf Host-Pfade außerhalb der Mounts scheitert; Timeout killt hängende Prozesse. |
| FR-SBX-2 | Kein Netz per Default; Egress opt-in je Lauf/Policy mit Allowlist (z.B. interne npm-Registry). | Default-Sandbox: curl nach extern scheitert; mit Policy-Freigabe erreicht nur Allowlist-Ziele (DNS/Proxy-Log). |
| FR-SBX-3 | Sandbox-Profile (Node, .NET, Python, …) als versionierte Images aus der internen Registry des Steuerdiensts; Profilwahl je Workspace/Agent. | Profilwechsel stellt andere Toolchain bereit; Images sind gepinnt (Digest), Pull nur aus interner Registry. |
| FR-SBX-4 | Terminal-Transparenz: Jede Ausführung streamt live in ein xterm.js-Panel; Nutzer kann eingreifen/abbrechen; vollständige Historie im Lauf gespeichert. | Ausgaben erscheinen live; Abbruch-Button wirkt; Historie nach Reload vorhanden. |
| FR-SBX-5 | Sandbox erhält keine Secrets (keine Keychain-Inhalte, kein Nutzer-ENV); benötigte Variablen werden explizit je Profil/Policy kuratiert. | ENV-Dump in der Sandbox enthält keine Tokens/Keys des Hosts. |
2.5 MCP-Connectors / Tools (FR-MCP)
| ID | Anforderung | AK |
|---|---|---|
| FR-MCP-1 | MCP-Client im Agent-Core (offizielles TS-SDK): lokale Server via stdio (Child-Prozesse), entfernte via Streamable HTTP. | Referenz-Server beider Transporte funktionieren (Tool-Discovery + Aufruf). |
| FR-MCP-2 | Kuratierter Connector-Katalog im Steuerdienst: geprüfte MCP-Server mit gepinnter Version und Konfig-Vorlage; Nicht-ADM können ausschließlich Katalog-Einträge nutzen, die ihre Rolle erlaubt. | DEP/DEV kann keinen unkatalogisierten Server registrieren (UI + API verweigern); Katalog-Update propagiert an Clients. |
| FR-MCP-3 | Priorisierte Connectors: GitHub, M365/Microsoft Graph (Mail, SharePoint/OneDrive), Snowflake sind als Katalog-Einträge konfiguriert und je Pilot-Agent nutzbar. | Je Connector ein End-to-End-Nachweis: Issue lesen (GitHub), Mail-Entwurf (M365), Read-only-Query (Snowflake). |
| FR-MCP-4 | Credentials: Nutzer-Credentials in OS-Keychain (safeStorage); OAuth über System-Browser; alternativ zentral verwaltete Service-Zugänge für DEP-Agenten (vom ADM hinterlegt, minimal berechtigt). | Tokens nie im Klartext auf Disk (Dateisystem-Check); DEP-Pilot funktioniert ohne eigene Token-Eingabe. |
| FR-MCP-5 | Tool-Gating: Jeder MCP-Call wird gegen die Rollen-/Manifest-Allowlist geprüft; nicht erlaubte Tools sind für das Modell unsichtbar (nicht nur blockiert); sensible Aktionen laufen über FR-CW-3-Gates. | Nicht erlaubtes Tool taucht in der Tool-Liste des Modells nicht auf; Blocklist-Test schlägt fehl; Audit-Events je Call. |
2.6 Skills & Subagenten-Bausteine (FR-SKILL)
| ID | Anforderung | AK |
|---|---|---|
| FR-SKILL-1 | Skills als Markdown-Pakete (SKILL.md + Assets), versioniert und signiert in der zentralen Skill-Registry; Clients synchronisieren read-only die Skills ihrer Rolle. | Skill-Update in der Registry erscheint nach Sync im Client; Signaturbruch ⇒ Skill wird nicht geladen + Warnung. |
| FR-SKILL-2 | Der Agent erkennt anwendbare Skills anhand Name/Beschreibung und lädt Instruktionen bei Bedarf in den Kontext (progressive disclosure statt Alles-im-Systemprompt). | Skill triggert bei passender Aufgabe (Testfall); ungenutzte Skills kosten keinen Kontext (Token-Messung). |
| FR-SKILL-3 | ADM kann lokale Entwurfs-Skills anlegen, testen und in die Registry promoten; DEP/DEV können Skills nicht ändern. | Promote-Flow (Entwurf → veröffentlicht → Rollenzuweisung) funktioniert; DEP-UI bietet keine Skill-Bearbeitung. |
2.7 Rollen & Rechte (FR-ROLE)
| ID | Anforderung | AK |
|---|---|---|
| FR-ROLE-1 | Rollenmodell: ADM, optional DEV, je Abteilung eine DEP-Rolle; Rechte als Policies (Ressource × Aktion × Scope), Rollen bündeln Policies; Rollen additiv erweiterbar ohne Code-Änderung. | Neue Abteilungsrolle ist rein über Daten (Steuerdienst-UI/API) anlegbar; Policy-Auswertung im Client + Server identisch (Shared-Contract). |
| FR-ROLE-2 | Login & Tokens: Eigene Nutzerverwaltung mit LDAP-Sync (Gruppen→Rollen-Mapping); kurzlebige Access-Tokens + Refresh; Inferenz-API-Keys vom Steuerdienst ausgestellt und rotierbar. | LDAP-Nutzer kann sich anmelden; Gruppenwechsel in LDAP ändert Rolle nach Sync; Key-Rotation invalidiert alte Keys (401 am Caddy). |
| FR-ROLE-3 | Offline-Degradation: Ohne Steuerdienst arbeitet der Client mit gecachten Policies/Manifests weiter (konfigurierbare Frist, Default 72 h); danach degradiert er auf read-only-Chat. | Steuerdienst aus ⇒ Arbeit läuft weiter; nach Fristablauf sind Schreib-Tools deaktiviert mit klarem Hinweis. |
| FR-ROLE-4 | Audit: Append-only-Audit zentral (Logins, Läufe, Tool-Calls, Datei-Writes als Pfad+Hash, Genehmigungen, Provisionierungs-Änderungen); Client puffert offline und batcht nach; Einsicht nur ADM. | Jede AK-relevante Aktion erzeugt ein Event; Offline-Events erscheinen nach Reconnect; DEP hat keinen Audit-Zugriff. |
2.8 Provisionierung & Verteilung (FR-PROV)
| ID | Anforderung | AK |
|---|---|---|
| FR-PROV-1 | Agenten-Manifeste: Agenten sind versionierte, signierte Manifeste (Modell, Endpoint-Referenz, Tool-/Datei-/KB-Scoping, Skills, Genehmigungsregeln, Audit-Level); Lebenszyklus draft → published → retired. | Manifest-Änderung erzeugt neue Version; Client prüft Signatur und lehnt manipulierte Manifeste ab; retired-Agent verschwindet beim nächsten Sync. |
| FR-PROV-2 | Rollen-Zuweisung: ADM weist Agenten Rollen zu; DEP-Clients zeigen ausschließlich provisionierte Agenten und bieten keine freie Agenten-/Modell-/Tool-Konfiguration. | DEP sieht nur zugewiesene Agenten; UI-Elemente für Konfiguration fehlen (nicht nur disabled). |
| FR-PROV-3 | Endpoint-Zuweisung: ADM weist Nutzern Inferenz-Ressourcen zu (Einzel-Mac oder Cluster); der Steuerdienst provisioniert den Host (Modelle via Ollama-API pullen, Proxy-Key setzen) und liefert dem Client Base-URL+Key. | Neuer Nutzer erhält nach Zuweisung automatisch funktionierenden Endpoint (Chat-Smoke-Test); Modell aus dem Manifest ist vorinstalliert. |
| FR-PROV-4 | Geführter First-Run: Beim ersten Start prüft die App Steuerdienst, Inferenz-Endpoint, Sandbox-Runtime und meldet je Komponente Status + Reparaturhinweis (Bootstrap-Erbe: idempotent, wiederholbar). | Alle Checks grün ⇒ App nutzbar; einzelner Fehler zeigt gezielten Hinweis (z.B. „Docker/WSL2 fehlt → Anleitung"). |
| FR-PROV-5 | App-Verteilung & Updates: Installer über internen Link; Updates über den internen Feed (TR-10) mit gestaffeltem Rollout (z.B. ADM zuerst). | Rollout-Stufen konfigurierbar; fehlerhaftes Update ist über den Feed zurückziehbar (Version-Pinning). |
2.9 Modell-Verwaltung (FR-MODEL)
| ID | Anforderung | AK |
|---|---|---|
| FR-MODEL-1 | ADM/DEV: Modelle des zugewiesenen Hosts auflisten, Details anzeigen, pullen (Fortschritts-Stream, hintergrund-fähig), löschen, laufende Modelle sehen/entladen — über die Plattform (Ollama-Proxy-Muster des Vorprojekts). | Pull zeigt Live-Fortschritt und überlebt Navigation; Entladen wirkt (/api/ps leer); DEP sieht diese Verwaltung nicht. |
| FR-MODEL-2 | Modell-Parameter (Temperatur, Top-P, Kontextlänge) je Agent/Konversation gemäß Rolle einstellbar; DEP-Werte kommen fix aus dem Manifest. | Parameter wirken auf die Inferenz (Stichprobe); DEP-UI ohne Parameter-Regler. |
2.10 Design / UI (FR-UI)
| ID | Anforderung | AK |
|---|---|---|
| FR-UI-1 | Claude-Desktop-Anmutung: ruhig, großzügig, viel Weißraum, runde Ecken, klare Typografie (System-Font-Stack), weiche Trennlinien; warme Neutraltöne mit einem Terracotta-Akzent; Statusfarben sparsam. | UI-Review gegen Design-Konzept (Konzept §10); keine „nackte" Komponenten-Library-Optik. |
| FR-UI-2 | Dark/Light mit System-Default, Umschalter, persistiert; Design-Tokens als CSS Custom Properties; keine Farb-Hardcodes in Komponenten. | Theme-Wechsel wirkt sofort und vollständig; Token-Audit (Stichprobe) ohne Hardcodes. |
| FR-UI-3 | Layout: einklappbare Sidebar (Konversationen/Agenten), Hauptfläche Chat/Cowork, Kontext-Panel (Dateibaum, Diff, Terminal, Tool-Aktivität); responsive ab ~1200 px Laptop-Breite. | Cowork-Ansicht zeigt Chat + Arbeitsbereich parallel; Sidebar-Zustand persistiert. |
| FR-UI-4 | Keine externen Laufzeit-Requests für Fonts/Icons/Assets (GDPR); Icons als eingebettete SVGs. | Netzwerk-Log während normaler Nutzung zeigt nur Inferenz-Host, Steuerdienst und freigegebene Connectors. |
| FR-UI-5 | UI-Sprache Deutsch (v1); Strings zentralisiert, sodass Lokalisierung später möglich bleibt (keine i18n-Maschinerie jetzt). | Alle sichtbaren Texte deutsch; String-Katalog existiert. |
2.11 Monitoring (FR-MON)
| ID | Anforderung | AK |
|---|---|---|
| FR-MON-1 | Metrics-Agent je Inferenz-Host (launchd): CPU-Last, GPU-Last (Metal), Unified-Memory (genutzt/gesamt), Leistungsaufnahme best-effort, geladene Modelle; Push an den Steuerdienst. | Werte plausibel gegen Activity Monitor/powermetrics; Ausfall des Agents ⇒ Host als „stale" markiert, kein Crash. |
| FR-MON-2 | Monitoring-Ansicht in der App: Nutzer sieht den eigenen Host live (SSE/Polling); ADM sieht alle Hosts + Cluster-Aggregate; nicht verfügbare Sensoren = „n/a". | Live-Aktualisierung ohne Reload; ADM-Gesamtsicht listet alle registrierten Hosts mit Status. |
| FR-MON-3 | Health-Übersicht: Erreichbarkeit Steuerdienst / eigener Endpoint / Sandbox-Runtime als Statusleiste (Vorprojekt-Muster „Dienste-Karte"). | Jeder Dienst zeigt verbunden/nicht erreichbar/nicht konfiguriert; Klick führt zu Reparaturhinweis. |
3. Nicht-funktionale Anforderungen (NFR)
| ID | Anforderung | AK |
|---|---|---|
| NFR-1 | Datenlokalität: Keine Nutzdaten (Prompts, Dateien, Ergebnisse) verlassen das Firmennetz, außer über explizit freigegebene Connectors (GitHub, M365, Snowflake) mit Rollen-Policy. | Netz-Audit eines Agent-Laufs zeigt nur erlaubte Ziele. |
| NFR-2 | Performance Chat: Erste Token <2 s nach Request im LAN (Modell geladen); UI bleibt bei Streaming und parallelen Läufen responsiv (keine Blockade >100 ms im Renderer). | Messung gegen Standard-Setup (M4 Pro 48 GB, 32B-Modell); UI-Jank-Profil unauffällig. |
| NFR-3 | Performance VPN: Chat und Agent-Läufe bleiben bei ≥50 ms RTT und kurzen Ausfällen (≤30 s) nutzbar (TR-5-Verhalten). | Test mit künstlicher Latenz/Drop: kein Lauf-Verlust, verständliche Status-UI. |
| NFR-4 | Sicherheit: Umsetzung der Maßnahmen aus Konzept §14; vor Pilot-Rollout ein interner Security-Review (Checkliste: Electron-Härtung, Sandbox-Escape-Tests, Endpoint-Scan, Secret-Handling). | Review-Protokoll ohne offene Kritikalitäten. |
| NFR-5 | Skalierbarkeit: Architektur trägt 50+ Nutzer ohne Umbau (Steuerdienst zustandslos skalierbar, DB-Indizes, Endpoint-Zuordnung 1:n-fähig); v1 wird für 2 ADM + 15 Nutzer betrieben. | Lasttest Steuerdienst-API mit 50 simulierten Clients ohne Degradation. |
| NFR-6 | Wartbarkeit: Ein Repo (Monorepo Client+Server+Shared), CI mit Build+Tests je Plattform, Conventional Commits, technische Doku parallel zur Entwicklung (Vorprojekt-Arbeitsweise). | CI grün als Merge-Bedingung; Doku-Pflicht im Definition-of-Done. |
| NFR-7 | Beobachtbarkeit Betrieb: Steuerdienst und Metrics-Pipeline loggen strukturiert; Admin kann Client-Diagnose-Bundle (Logs ohne Secrets) exportieren lassen. | Diagnose-Bundle enthält keine Tokens (Filtertest). |
4. Abgrenzung (Out of Scope v1)
Browser-Steuerung/Computer-Use, Sprach-I/O, Mobile, serverseitiger Agent-Runner, Konversations-Sync über Geräte, Fine-Tuning/Training, Marketplace/freie MCP-Installation für Nicht-ADM, Abrechnung/Quotas. Begründungen: Konzept §12.3.
5. Offene Punkte
Siehe Konzept §15 (Annahmen A1–A7, Fragen F1–F6). Anforderungen, die von offenen Fragen abhängen, sind: FR-ROLE-1 (F1), FR-MCP-3 (F2/F3), FR-CW-6 (F5), FR-ROLE-4 (F6).