# Nexus Sites Mockup: Mission-Control-Evaluation **Stand:** 2026-07-28 **Artefakt:** `sites/nexus-mission-control` **Umfang:** 18 bedienbare Routen, ausschließlich deterministische Mockdaten **Zielbild:** Nexus als agent-first Bedienoberfläche über OpenClaw; OpenAI bleibt der primäre Modellprovider innerhalb von OpenClaw. ## Kurzurteil Der Sites-Mockup ist als visuelles und interaktives Zielbild überzeugend. Die Navigation ist konsistent, Iris bleibt kontextuell erreichbar und die neue Run-Control-Seite macht Ziel, Agentenhierarchie, Budget, aktuellen Schritt, Freigabegrenze und Wiederaufnahme erstmals gemeinsam sichtbar. **Bewertung des Zielbilds:** | Dimension | Wertung | Urteil | |---|---:|---| | Visuelle Konsistenz und Informationshierarchie | 4,5 / 5 | Stark | | Agent-first Bedienmodell | 3,7 / 5 | Gute Richtung | | Abdeckung des täglichen Mission-Control-Betriebs | 2,9 / 5 | Wesentliche Flächen fehlen | | Nachweis realer Betriebsfähigkeit | 0 / 5 | Absichtlich nicht Teil dieses statischen Mockups | Der Mockup zeigt damit ein belastbares Produktziel, aber noch keine produktive Control Plane. Er ruft weder Nexus noch OpenClaw, OpenAI, Authentifizierung, Persistenz, Analytics oder andere Provider auf. Alle sichtbaren Daten und Interaktionen werden im Browser aus einem fest definierten Fixture erzeugt und bei einem Reload zurückgesetzt. ## Visuelle Evidenz ![Alle 18 geprüften Routen](./route-contact-sheet.png) ![Referenz-, Breakpoint- und Detailzustände](./evidence-contact-sheet.png) ### Veröffentlichtes Sites-Artefakt ![Privat veröffentlichtes Dashboard](./24-deployed-dashboard.png) ![Privat veröffentlichte Run-Control-Seite](./25-deployed-run-control.png) ## Verbindlicher Mission-Control-Vertrag Die folgenden Anforderungen ergeben sich sowohl aus dem Nexus-Zielbild als auch aus den aktuellen Runtime-Schnittstellen: 1. **OpenClaw bleibt die Runtime-Quelle.** Das [OpenClaw Gateway Protocol](https://docs.openclaw.ai/gateway/protocol) stellt den typisierten Control-Plane-Zugang für Status, Sessions, Runs, Tools, Approvals, Cron, Nodes und Ereignisse bereit. Nexus sollte diesen Vertrag serverseitig hinter domänenspezifischen Read-/Control-Clients kapseln; der Browser darf weder Gateway-Credentials noch rohe RPC-Rechte erhalten. 2. **Freigaben sind Teil des Run-Zustands.** Der [OpenAI Agents SDK HITL-Flow](https://openai.github.io/openai-agents-js/guides/human-in-the-loop/) pausiert Ausführungen vor einem freigabepflichtigen Tool-Aufruf und setzt sie aus demselben `RunState` fort. Die Run-Control-Darstellung braucht deshalb dauerhafte, versionierte Checkpoints statt lokaler UI-Schalter. 3. **Jede Ausführung braucht beweisbare Ereignisse.** Das [OpenAI Agents SDK Tracing](https://openai.github.io/openai-agents-js/guides/tracing/) bildet Agenten-, Modell-, Tool-, Handoff- und Guardrail-Arbeit als verschachtelte Spans ab. Nexus benötigt einen korrelierten Run-/Event-Read Model mit gezielter Redaction sensitiver Inhalte. 4. **Tool-Rechte ersetzen keine Freigabeoberfläche.** Die [OpenClaw Tools Invoke API](https://docs.openclaw.ai/gateway/tools-invoke-http-api) fügt für erreichbare Tools nicht automatisch eine zusätzliche Einzel-Freigabe hinzu und sperrt besonders riskante Shell-, Datei-, Session-, Cron-, Gateway- und Node-Flächen standardmäßig. Nexus muss Least-Privilege-Policies und seine menschlichen Freigabegrenzen explizit modellieren. 5. **Automationen sind laufende Arbeit, keine Kalenderdekoration.** [OpenClaw Scheduled Tasks](https://docs.openclaw.ai/automation/cron-jobs) besitzen persistente Jobs, Ausführungshistorie, Fehlerzustände, Retry/Backoff und Session-Modi. Die Calendar-Seite muss diesen vollständigen Lebenszyklus abbilden. ## Evaluation aller Seiten Skala für **Mockup-Reife**: 1 = Platzhalter, 3 = verständlicher Teilfluss, 5 = belastbares interaktives Zielbild. Die Wertung bewertet nicht die reale Backend-Funktion. | Route | Rolle im Mission Control | Mockup-Reife | Was bereits gut funktioniert | Was für den produktiven Zielzustand fehlt | Priorität | |---|---|---:|---|---|---| | `/login` | Sicherer Zugang | 3,5 / 5 | Ruhiger Einstieg, Passwortzustand, klare Produktidentität | SSO/Passkeys/2FA, Recovery, Geräte und Sessions, Return-to-Route, Lockout- und Break-glass-Flows | P1 | | `/dashboard` | Lagebild und Einstieg | 4,5 / 5 | Dominante Live-Orchestrierung, knappe Statusleisten, Agentenpfad, Iris als Modal | Autoritative Run-/Queue-Daten, globale Command Bar, Provider-/Budgetalarme, echte Offline-/Stale-/Partial-Zustände, Deep Link zum Run | P0 | | `/runs` | Aktive Ausführung steuern | 4,5 / 5 | Ziel, Hierarchie, aktueller Agent, Budget, Event Rail, zweistufige Freigabe, Pause/Stop/Resume/Checkpoint | Dauerhafte Run-ID und State-Version, Toolargumente/Diff, Artifact-Preview, Idempotenz, Race-Konflikte, Replay-Sicherheit, vollständige Trace-Suche | P0 | | `/agents` | Runtime-Workforce | 4 / 5 | Rollen, Status, Modell und Policy sind scanbar; Karten führen in Details | Create/Import, Enable/Disable/Restart, Capability- und Permission-Diff, Auslastung, Kosten, Drift und Versionsstatus | P1 | | `/agents/:id` | Agent Cockpit | 4 / 5 | Identität, Live-Zusammenfassung, Aktivität und Konfiguration sind sinnvoll gruppiert | Sessions/Runs, Toolrechte, Modellpolicy, Workspace, Budget, Secrets-Referenzen, Evals, Lifecycle und Rollback | P1 | | `/projects` | Portfolio und Outcomes | 3,5 / 5 | Projekte und Fortschritt sind schnell erfassbar; Karten sind klickbar | Ziele/KPIs, verantwortliche Agenten, aktive Runs, Budget, Risiken, Artifacts, Automationen und Health-Aggregation | P1 | | `/projects/:id` | Outcome Control | 3,5 / 5 | Projektkontext und Aufgabenfortschritt sind verdichtet | Delegation, Runstart, Agententeam, Timeline, Abhängigkeiten, Budget, Playbooks, Artifacts und Abschlusskriterien | P1 | | `/tasks` | Agentische Arbeitswarteschlange | 4 / 5 | Board, Erstellen, Status und Assignee sind bedienbar; fachlich horizontales Board bleibt intern scrollbar | Run-/Approval-Verknüpfung, Dependencies, Bulk-Aktionen, Retry/Resume/Cancel, Queue-SLAs, Blocker und ehrliche Fehlerzustände | P1 | | `/tasks/:id` | Einzelauftrag steuern | 4 / 5 | Bearbeitung, Agentenzuweisung, Status und Kontext sind gut nutzbar | Session/Run, Tool Calls, Approvals, Artifacts, Checkpoints, Replay, Abhängigkeiten und Abnahmeevidenz | P1 | | `/memory` | Kuratiertes Langzeitwissen | 3,5 / 5 | Suche, Liste und anklickbare Detailansicht funktionieren | Create/Edit/Archive, Provenienz, Scope, Freshness, Retention, Konflikte, Retrieval-Test und Versions-Rollback | P1 | | `/docs` | Knowledge Ingestion | 3,5 / 5 | Kategorien, Suche und Dokumentdetail sind verständlich | Upload/Import/Authoring, Ingestionstatus, Parserfehler, Zitate, Versionen, Freigaben, Sync und Retrieval-Evals | P1 | | `/models` | OpenAI-Policy über OpenClaw | 3 / 5 | Primär-/Fallback-Routing und Status sind klar dargestellt | Auth-Profilstatus ohne Secrets, Fähigkeiten, Limits, Qualität/Kosten/Latenz, Policy-Diff, Testlauf, Circuit Breaker und Rollback | P0 | | `/activity` | Audit- und Eventstream | 3,5 / 5 | Filterbarer, chronologischer Überblick | Autoritative Eventquelle, Run-/Correlation-ID, Actor, Diff, Payload-Redaction, Suche, Export, Retention und Deep Links | P0 | | `/calendar` | Scheduler und Automation | 3,5 / 5 | Upcoming und Jobs sind getrennt und scanbar | Vollständiges Cron-CRUD, Run now, Pause/Resume, Owner, Zeitzone, Session Mode, Run History, Retry, Delivery und Fehlerdiagnose | P1 | | `/security` | Sicherheits- und Policy-Lage | 3,5 / 5 | Auth-, Token-, Rate- und Transportkonfiguration sind als Übersicht lesbar | Tatsächliche effektive Scopes, Findings, Remediation, Schlüsselrotation, Nutzergeräte, Secret-Referenzen, Auditbelege und Drift | P0 | | `/incidents` | Operative Störungsbearbeitung | 3,5 / 5 | Liste und anklickbares Incident-Detail funktionieren | Create/Acknowledge/Assign, Severity, Timeline, Run-/Provider-Korrelation, Playbook, Remediation, Resolve und Postmortem | P1 | | `/notifications` | Persönliche Action Inbox | 3,5 / 5 | Read/Read-all und Priorisierung sind verständlich | Acknowledge, Snooze, Assignee, Quiet Hours, Routingregeln, Kanalpräferenzen sowie direkte Approval-/Incident-Aktionen | P1 | | `/settings` | Control-Plane-Konfiguration | 3 / 5 | Profil, Passwort und Benutzerverwaltung sind klar getrennt | Gateway-/OpenAI-via-OpenClaw-Status, Rollen, Tools, Approval Policies, Budgets, Connectoren, Retention, Secrets-Referenzen und Audit | P0 | Die frühere Mobile-Chat-Seite ist bewusst entfernt. `/chat` leitet im Mockup auf `/dashboard` um; Iris bleibt auf jeder authentifizierten Seite als kontextuelles Modal verfügbar. ## Produktweite Lücken ### P0 – Vor jeder realen Steuerung - Typisierte Nexus-Fassade für den OpenClaw-Gateway-Vertrag mit Capability-Discovery und kompatibler Protokollversion. - Authenticated-by-default, getrennte Benutzer-/Service-/Agentenidentitäten, Least-Privilege-Scopes und keinerlei Secrets im Browser. - Dauerhafte Domäne für Run, Session, Parent/Child-Agent, Tool Call, Approval, Artifact, Usage, Budget und State-Version. - Jede Mutation mit Actor, Correlation ID, Idempotency Key, erwarteter Version, Policyentscheidung, Ergebnis und unveränderbarem Audit-Eintrag. - Recovery für Reconnect, Reload, Gateway-Neustart, verlorene Events, doppelte Zustellung und bereits ausgeführte Seiteneffekte. - Zentrale Approval Inbox mit Ablaufzeit, Begründung, exaktem Ziel, Toolargumenten, Konsequenz, Reviewerbindung und First-answer-wins-Semantik. ### P1 – Täglicher agent-first Betrieb - Globale Command Bar: Ziel formulieren, Kontext prüfen, Plan freigeben und direkt einen dauerhaften Run starten. - Eigene Deep Links für `/runs/:id` und eine zentrale `/approvals`-Arbeitsfläche. - Tool-Katalog und effektive Rechte, Artifact-Browser, Session Explorer und vollständiger Scheduler-Lifecycle. - Kontextuelle Delegation auf Projekt, Task, Incident, Dokument und Zeitplan. - Quellen- und Freshness-Markierung für jede operative Zahl; Offline, Stale, Partial, Unauthorized und Incompatible dürfen nicht wie leere Daten wirken. - Provider-Quoten, Budgets, Fallbacks, Circuit Breaker und kostenbewusste Routingregeln für OpenAI innerhalb von OpenClaw. ### P2 – Qualität und Plattformreife - Eval-Arbeitsfläche für Datensätze, Run-Vergleiche, Regressionen, Tool-Argumentgenauigkeit und Release Gates. - Gespeicherte Ansichten, globale Suche, Command-History und Operator-Shortcuts. - SLOs für Agentenqualität, Latenz, Kosten, Queuezeit und Approval-SLA. - Wiederverwendbare Run-, Agenten-, Incident- und Automations-Playbooks. - Channels, Connectors und Nodes erst nach stabiler Trust-, Approval- und Recovery-Schicht als eigenständige Flächen ergänzen. ## Empfohlene nächste Mockups 1. `/approvals` als zentrale, risiko- und SLA-sortierte Freigabe-Inbox. 2. `/runs/:id` als dauerhafter Run-Explorer mit Trace, Tooldiff und Artifacts. 3. `/tools` als Katalog für Schemas, effektive Rechte und Policy-Diffs. 4. `/artifacts` als nachvollziehbare Output- und Provenienzfläche. 5. `/evals` als Vergleichs- und Release-Gate-Arbeitsfläche. ## Durchgeführte Abnahme | Prüfung | Ergebnis | |---|---| | Registrierte Zielrouten | 18 / 18 visuell geprüft | | Geometrie-/Overflow-Matrix | 90 Prüfungen bei 375, 768, 1024, 1440 und 1920 px; kein dokumentweiter horizontaler Overflow | | Run Control | Approval Review/Confirm/Undo, Pause/Resume, Stop/Checkpoint-Restart und Eventdetail bedient | | Kerninteraktionen | Navigation, Detailwechsel, Filter, Formulare, Task-Erstellung, Settings, Notifications und Iris-Modal bedient | | Browserkonsole | Keine Fehler oder Warnungen im geprüften Ablauf | | TypeScript | `npm run typecheck` erfolgreich | | Komponententests | `npm test` erfolgreich | | Sites-Build | `npm run build` erfolgreich | | Worker-/SPA-Routing | `npm run test:sites` erfolgreich | | Private Sites-Produktion | Version 2 erfolgreich; Dashboard, Run Control und zweistufige Approval-Interaktion bedient; keine aktuellen Workerfehler | ## Entscheidung **Sites-Freigabe als Mockup: Go.** **Produktiver Einsatz als Mission Control: No-Go.** Der nächste Umsetzungsslice sollte nicht noch eine reine Übersichtsseite sein. Er sollte `/runs` mit einer dauerhaften OpenClaw-Session, dem autoritativen Eventstream und einer echten Approval-Grenze verbinden. Erst dann wird aus dem visuellen Mission-Control-Versprechen eine belastbare Control Plane.