nexus/docs/audits/2026-07-27/agent-first-evaluation/PAGE_AND_CAPABILITY_EVALUATION.md

Nexus: Seiten- und Agent-First-Evaluation

Datum: 2026-07-27 Commit-Basis: 3bc7622 plus uncommittete Design-Migration im Working Tree Routen: 18 registrierte Routen Ziel: Nexus als alleinige tägliche Mission-Control-Oberfläche und agent-first Control Plane über OpenClaw, mit OpenAI als primärem Provider innerhalb von OpenClaw

Kurzurteil

Nexus ist inzwischen ein visuell eigenständiges und deutlich kohärenteres Operations-Cockpit. Das Task-System, Agentenprofil und die Gateway-Anbindung bilden eine belastbare Basis. Für das konkretisierte Produktziel ist es aber noch kein vollständiger Ersatz für die tägliche OpenClaw-Oberfläche und noch keine durchgehend agent-first Control Plane.

Zielreife: 40 / 100 Entscheidung: No-Go für OpenClaw-UI-Unabhängigkeit, aber brauchbare interne Alpha als Dashboard und Task-Orchestrierung.

Die frühere Bewertung von 54/100 maß die Release-Reife des damaligen Funktionsumfangs. Die aktuelle 40/100 misst den größeren, nun verbindlichen Zielumfang: tägliche OpenClaw-Bedienparität in Nexus, OpenAI als Primärprovider in OpenClaw und dauerhafte agentische Steuerung.

Architekturkorrektur: Die ursprüngliche Fassung dieser Evaluation nahm einen direkten OpenAI-Pfad in Nexus und einen optionalen OpenClaw-Adapter an. Verbindlich ist stattdessen Nexus -> OpenClaw -> OpenAI. Die Zielreife bleibt bei 40/100, weil die unveränderten Security-, Session-, Control-, Eval- und Bedienlücken den produktiven End-to-End-Betrieb weiterhin blockieren.

Bewertungsmodell

Bereich	Gewicht	Reife	Gewichteter Beitrag
OpenClaw-UI-Unabhängigkeit / Steuerungsparität	25 %	28	7,0
Agent-first Workflows	20 %	35	7,0
OpenAI-over-OpenClaw Providersteuerung	15 %	20	3,0
Seiten-UX, Design und Accessibility	15 %	74	11,1
Domäne und Backend-Architektur	10 %	70	7,0
Security und Governance	10 %	25	2,5
Tests, Tracing, Evals und Observability	5 %	40	2,0
Gesamt	100 %		39,6 -> 40

Evidenz und Grenzen

• Der aktuelle Kernfluss Dashboard -> Agents -> Agent Detail -> Projects wurde in diesem Lauf bei 1440 x 1000 im Browser erfasst und visuell geprüft.
• Nach einem vollständigen Routen-Reload war die Preview-Authentifizierung nicht mehr verfügbar. Deshalb wurden die übrigen 14 Routen anhand ihrer aktuellen Vue-Komponenten, Stores, Routerziele, API-Aufrufe und Backend-Verträge geprüft.
• Es wurde kein produktiver OpenClaw-, PostgreSQL-, Proxy- oder Provider-End-to-End-Lauf ausgeführt.
• Dies ist keine vollständige WCAG-, Penetrations- oder Lastprüfung.
• Bestehende Codeänderungen wurden in diesem Evaluationsschritt nicht funktional verändert.

Frischer visueller Kernfluss

1. Dashboard - visuell stark, funktional teilweise

Die Live-Orchestrierung besitzt klare Hierarchie und genügend Arbeitsfläche. Status- und Task-Leisten sind sinnvoll verdichtet. Kritisch bleiben die nicht-funktionale Suchaffordance, der lokale statt persistente „Agent hinzufügen“-Vorgang und fehlende Run-/Trace-Aktionen.

2. Agents - gute Übersicht, unvollständige Steuerung

Rollen, Status und Gateway-Zustand sind schnell erfassbar. Es fehlen Lebenszyklusaktionen wie Erstellen, Importieren, Aktivieren, Deaktivieren, Neustarten und Capability-/Policy-Übersichten.

3. Agent Detail - gute Diagnosebasis, kein vollständiges Agent Cockpit

Profil, aktuelle Aktivität und Config-Dateien bilden eine brauchbare Basis. Sessions, Runs, Tools, Freigaben, Budgets, Evals und Lifecycle-Steuerung fehlen. „Zurück zum Team“ navigiert weiterhin auf das nicht registrierte /team und wird durch den Wildcard-Redirect maskiert.

4. Projects - Kernaktion vorhanden, Zustand nicht erklärt

Ein Projekt kann angelegt werden. Wenn der Operations-Snapshot nicht geladen ist, bleibt danach eine große leere Fläche ohne klaren Empty-, Error- oder Reconnect-Zustand. Agenten, Runs, Ziele, Artefakte und Budgets sind nicht Teil der Portfolioansicht.

Evaluation aller 18 Seiten

Skala: 1 = Platzhalter/Blocker, 3 = brauchbare Teilfunktion, 5 = Zielzustand.

Route	Reife	Was heute funktioniert	Was verbessert werden muss / fehlt	Priorität
/login	3,5/5	Owner-Login, Passwortsichtbarkeit, Rate-Limit-Feedback	Recovery, 2FA/Passkeys, Session-/Geräteverwaltung, sauberer Return-to-Route-Flow	P1
/dashboard	3/5	Live-Topologie, Status, Fokus-Tasks, Iris-Modal, Modellwechsel	Echte Command Bar; „Agent hinzufügen“ persistieren; Run-IDs, Trace, Kosten, Tool-Aufrufe, Pause/Resume/Cancel; klare Offline-/Error-Zustände	P0
/memory	2/5	Liste, Suche, Lesen	Erstellen, Bearbeiten, Löschen, Quellen/Freshness, Versionen, Scope, Retrieval-Tests, Retention und Memory Policies	P1
/docs	2/5	Liste, Kategorien, Suche, Lesen	Upload, Authoring, Sync/Import, Versionen, Zitierbarkeit, Ingestion-Status, Freigaben und Knowledge-Tests	P1
/agents/:id	2,5/5	Profil, Live-Zusammenfassung, Aktivität, erlaubte Config-Dateien speichern	Defekten /team-Backlink korrigieren; Runs/Sessions, Lifecycle, Tools/Rechte, Budgets, Secrets-Referenzen, Evals und Restart	P0
/security	1,5/5	Read-only Statusübersicht	Tatsächliche Policy-/Auth-Lage statt nur Konfigurationswerte; Remediation, Sessions, Schlüsselrotation, Audit, 2FA/Passkeys und Security Alerts	P0
/incidents	2/5	Incident-Liste und Detail lesen	Erstellen, Acknowledge, Zuweisen, Severity/Timeline, Remediation-Aktionen, Verknüpfung mit Run/Task, Resolve und Postmortem	P1
/calendar	2/5	Cron-/Upcoming-Liste und Refresh	Erstellen, Bearbeiten, Pause/Resume, Run now, Retry, Löschen, Zeitzone, Owner, Run-Historie und Fehlerdetails	P0
/projects	2/5	Projekt anlegen, Karten aus Operations-Snapshot öffnen	Explizite Loading/Empty/Error-Zustände; Ziele, Agententeam, Runs, Tasks, Artefakte, Kosten, Health und Automationen	P1
/projects/:id	2,5/5	Projekt bearbeiten/archivieren, zugehörige Tasks lesen	Task/Run direkt anlegen und delegieren; Ziel/KPI, Team, Artefakte, Timeline, Budget und Automationen	P1
/tasks	4/5	Erstellen, Board, Statuswechsel, Iris-Waiting, Detailpanel, Subtasks, Editieren	Board-Level-Fehler sichtbar machen; Run-/Trace-Bezug, Abhängigkeiten, Bulk-Aktionen, einheitliche Approval Queue, Cancel/Retry/Resume	P1
/tasks/:id	4/5	Vollständiges Editieren, Status/Priorität, Assignee, Due Date, Subtasks, Aktivität/Kommentare	Agent Run, Tool-Aufrufe, Outputs/Artefakte, Approval-Historie, Retry/Resume/Cancel und Abhängigkeitsgraph	P1
/agents	3/5	Agenteninventar, Gateway-Status, Profileinstieg	Create/Import/Disable/Delete/Restart, Filter, Capability- und Permission-Summary, Run-Last und Kosten	P1
/models	1,5/5	Read-only Routing-Liste	OpenAI-Primärpolicy über OpenClaw, Modellkatalog, sichere Auth-Profil-/Secret-Referenzen, Defaults, Fallbacks, Limits, Preis/Qualität/Latenz und Tests	P0
/activity	2/5	Snapshot-Timeline, Typfilter, Sortierung, Pagination	Autoritativer Event-Stream, Suche, Run-/Correlation-ID, Actor, Diff, Export, Retention und sichere Payload-Ansicht	P1
/chat	1,5/5	Einzelne Iris-Nachrichten an /api/v1/chat, lokale Conversation-ID	Persistente Threadliste, Streaming, Anhänge, Tool-/Approval-Karten, Run-Erstellung, Stop/Retry/Resume, Kontextkontrolle; „Preview“ ablösen	P0
/notifications	2,5/5	Liste, Read/Read-all, Tastaturbedienung	Loading/Error darstellen; Task-Detail statt nur Board; Acknowledge/Snooze, Preferences, Kanäle, Routingregeln und Approval-Aktionen	P1
/settings	2,5/5	Profil, Passwort, Benutzerverwaltung	Gateway-/Provider-Setup, OpenAI-Status und sichere OpenClaw-Secret-Referenzen, Modellpolitik, Tool-Rechte, Approval Policies, Budgets, Connectoren, Retention, Rollen und Audit	P0

Produktweite Kernbefunde

1. Sichtbare Kernaktionen sind teilweise inert oder nur lokal

• Die Suchleisten in beiden Shells sind keine Inputs und öffnen keine Command Palette.
• „Ask Iris“ in der Legacy-Topbar besitzt keinen Click-Handler.
• „Agent hinzufügen“ auf dem Dashboard fügt einen Agenten nur in den lokalen Pinia-Zustand ein; es entsteht kein Agent im Backend oder Runtime-System.
• Mehrere Stores schlucken Fehler und zeigen dann leere oder scheinbar erfolgreiche Flächen.

Für eine agent-first Oberfläche sind dies Hard Blocker, weil genau diese Affordanzen den primären Arbeitsweg versprechen.

2. Der OpenClaw-Pfad ist korrekt, die OpenAI-Primärpolicy aber unvollständig

IAgentRuntime bietet nur Status und Chat. Der einzige registrierte Adapter ist OpenClawRuntime; das entspricht der verbindlichen Zielarchitektur. ModelRoutingService führt jedoch zwei DeepSeek-Ziele und ein OpenAI-Ziel auf. Damit ist OpenAI noch nicht als primärer Provider für die relevanten Agentenrollen belegt. Es fehlen eine sichere OpenClaw-Auth-Profilverwaltung, rollenbezogene OpenAI-Policies, Live-Providerbeleg, dauerhafte Session-/Subagent-Korrelation, Streaming, Tool-Lifecycle, Freigaben und Tracing.

3. Die Task-Domäne ist der stärkste agentische Kern

Task Board, Task Detail, Child Tasks, Handoffs, Aktivität, Approval-Aktionen und die zehn Nexus-MCP-Tools bilden den besten vorhandenen Baustein. Das MCP ist aber noch auf die Task-Domäne begrenzt und deckt weder Runs/Sessions noch Tools, Provider, Zeitpläne, Wissen oder Artefakte ab.

4. Live-Orchestrierung ist noch keine autoritative Run-Ansicht

Agentenstatus und Aktivität werden gepollt; Teile der „Thinking“-Darstellung werden präsentativ aus Texten abgeleitet. Token- und Kostenwerte sind in der Agent-Mapping-Schicht derzeit Defaultwerte. Für operative Entscheidungen braucht die Ansicht dauerhafte Run-, Event-, Usage- und Trace-Daten.

5. Security blockiert eine produktive Control Plane

• AddAuthorization() besitzt keine authenticated-by-default Fallback Policy. Mehrere /api/v1-Controller sind nicht mit [Authorize] geschützt.
• Bridge und MCP akzeptieren einen bekannten, vom Aufrufer gesetzten X-Agent-Id als Identität, bevor ein starker Service-Nachweis verlangt wird.
• Die Task-Board-/Stale-Endpunkte sind [AllowAnonymous] und autorisieren teilweise über denselben Header.
• docs/gateway-api-research.md enthält credential-artige Literalwerte. Diese müssen als kompromittiert behandelt, rotiert, aus dem Working Tree und gegebenenfalls aus der Git-Historie entfernt werden.

Die Security-Seite zeigt Konfigurationswerte, macht diese strukturellen Release-Blocker aber nicht sichtbar.

Unabhängigkeit von der OpenClaw-Oberfläche: Capability-Parität

Capability	Aktueller Stand	Lücke
Gateway Health/Version	Vorhanden	Konfiguration, Reload, Update und Recovery fehlen
Agenteninventar/Config	Teilweise	Vollständiger Lifecycle und Policies fehlen
Chat	Teilweise	Persistente Sessions, Streaming, Tools und Run-Steuerung fehlen
Tasks/Delegation	Stark	Run-/Trace-/Artifact-Bezug und einheitliche Approvals fehlen
Sessions/Runs	Fehlt	Listen, starten, resume, branch, cancel, retry, terminate
Subagenten/Handoffs	Task-Handoff teilweise	Run-Hierarchie, Spawn/Stop und Ownership fehlen
Tool-Katalog/Rechte	Fehlt	Schema, Namespace, Allowlist, Approval Policy, Audit
Cron/Schedules	Read-only UI	Vollständiger CRUD- und Ausführungs-Lifecycle fehlt
Modelle/Provider	Read-only/hardcodiert	OpenAI-Primärpolicy in OpenClaw, sichere Auth-Profile, Routing, Fallbacks und Live-Beleg fehlen
Memory/Docs	Read-only	Ingestion, Schreiben, Kuratierung, Versionen und Tests fehlen
Dateien/Artefakte	Config-Markdown teilweise	Allgemeiner Upload/Download, Versionierung, Run-Zuordnung fehlt
Channels/Connectors	Fehlt	Einrichtung, Status, Rechte und Datenfreigaben fehlen
Nodes/Hosts	Fehlt	Inventar, Health und kontrollierte Runtime-Aktionen fehlen
Approvals	Task-Approval teilweise	Zentrale Tool-/Run-/Datenfreigaben fehlen
Traces/Evals/Usage	Fehlt/teilweise abgeleitet	Autoritative Runs, Tool-Traces, Kosten, Latenz und Eval-Suites fehlen
Secrets	Fehlt	Sichere Verwaltung, Rotation und Referenzen fehlen
Incidents/Notifications	Read-mostly	Operative Bearbeitung, Eskalation und Remediation fehlen

Empfohlene Zielarchitektur

Der vorhandene C#-Stack und OpenClaw-Pfad werden gezielt ausgebaut:

1. Nexus bleibt Product Control Plane: ASP.NET Core besitzt Nutzer, RBAC, Projekte, Tasks, menschliche Freigaben und das Control-Plane-Audit.
2. OpenClaw bleibt verpflichtende Runtime: Agenten, Sessions, Subagenten, Tools, Cron, Channels, Nodes und Modellrouting bleiben dort autoritativ.
3. OpenAI wird Primärprovider in OpenClaw: Credentials liegen ausschließlich in OpenClaw; Nexus zeigt und ändert nur sichere Referenzen und Policies.
4. Typisierte Gateway-Fassade: Der generische Gatewayclient wird in sichere Read-/Control-Verträge mit Scopes, Schema, Idempotenz, Versionsprüfung, Approval und Audit aufgeteilt.
5. Keine doppelte Runtime: Nexus korreliert OpenClaw-Sessions mit Tasks, Projekten, Approvals und Artifacts, baut aber keinen zweiten Session Store.

Siehe den kanonischen Zielvertrag: docs/AGENT_FIRST_MISSION_CONTROL.md und die vollständige docs/MISSION_CONTROL_ROADMAP.md.

Relevante Primärquellen:

• OpenClaw Gateway und Runtimekonzept
• OpenClaw Provider und Modellreferenzen
• OpenClaw Operator-Scopes
• OpenAI API-Key-Sicherheit
• Evaluation best practices

Priorisierte Roadmap

P0 - Control-Plane-Grundlage und Vertrauen

1. Authenticated-by-default erzwingen, Agent-/Service-Identität stark authentifizieren, negative Proxy-End-to-End-Tests ergänzen und credential-artige Werte rotieren/entfernen.
2. Durable-Run-Domäne mit Session, Parent/Child, Events, Tools, Approvals, Artefakten, Usage und Audit einführen.
3. OpenAI in OpenClaw als Primärprovider konfigurieren, sichere Auth-Profil-/Secret-Referenzen verwenden und den realen Nexus-OpenClaw-OpenAI-Pfad Ende-zu-Ende belegen.
4. Globale Command Bar und „Ask Iris“ auf jeder Seite funktional machen; sichtbare lokale/platzhalterhafte Aktionen entweder persistieren oder klar als Simulation kennzeichnen.
5. Agent-, Session-, Tool-/Permission-, Model-/Provider-, Secret- und Schedule-Lifecycle als erste OpenClaw-Paritätsstufe liefern.
6. Defekten /team-Backlink, fehlende Route-/Session-Hydration und verschluckte Kernfehler schließen.

P1 - Agentischer Betriebsalltag

1. Run Explorer mit Streaming, Trace, Tool-Aufrufen, Approval-Karten, Cancel/Retry/Resume und Artefakten.
2. Kontextuelle Delegation und Automatisierung auf Project, Task, Incident, Doc und Calendar.
3. Memory-/Docs-Ingestion, Versionierung, Herkunft/Freshness und Retrieval-Evals.
4. Zentrale Approval Inbox, operative Notifications und Incident-Remediation.
5. Modellrouting mit OpenAI-Defaults, Fallbacks, Budgets, Limits, Kosten-/Latenz-/Qualitätsvergleich.
6. Autoritativer Event-Stream mit Korrelation, Retention, Suche und Export.

P2 - Plattformreife

1. Channels, Connectors, Nodes/Hosts und kontrollierte Gateway-Administration.
2. Eval-Dashboard, Regression-Datasets, Prompt-/Policy-Versionen und Qualitätsgates.
3. Run-/Agent-Templates, wiederverwendbare Automationen und Projekt-Playbooks.
4. Granulare Rollen, Mandanten-/Teamgrenzen, Aufbewahrung und Compliance.

Abnahme für „kein OpenClaw-Wechsel mehr“

• Ein kompletter Workflow von Absicht -> Plan -> Agent/Subagent -> Tool Approval -> Artefakt -> Review -> Abschluss ist ausschließlich in Nexus bedienbar.
• Runs und Sessions können nach Reload oder Neustart fortgesetzt werden.
• Jede riskante Aktion besitzt Policy, Freigabe und Audit-Eintrag.
• Jede Modellinferenz aus Nexus läuft über OpenClaw; OpenAI ist dort als Primärprovider nachgewiesen und Nexus besitzt keinen direkten OpenAI-Pfad.
• Alle 18 Routen besitzen Route-, Loading-, Empty-, Error-, Keyboard- und Responsive-Smoke-Tests.
• Reale Provider-/Gateway-/PostgreSQL-/Proxy-End-to-End-Tests sind grün.
• Tool-Auswahl, Argumente, Ergebnisqualität, Kosten und Latenz werden durch reproduzierbare Evals geprüft.

Schlussfolgerung

Nexus sollte nicht neu begonnen werden. Die vorhandene Task-Domäne, Backend-Schichtung, Gateway-Abstraktion und neue Designsprache sind wertvoll. Der nächste Meilenstein darf jedoch keine weitere reine Seitenrunde sein: Zuerst müssen Security, eine typisierte OpenClaw Control Plane, der belegte OpenAI-Primärbetrieb in OpenClaw und die universelle Iris-/Session-Steuerung den tatsächlichen Control-Plane-Kern bilden.