nexus/docs/MISSION_CONTROL_ROADMAP.md

# Nexus Mission Control Roadmap

**Status:** Kanonische Produkt- und Umsetzungsroadmap
**Stand:** 2026-07-31
**Priorisierung:** Abhängigkeiten und Risikoreduktion statt willkürlicher
Kalendertermine
**Ziel:** Nexus ersetzt die OpenClaw-Oberfläche im täglichen Betrieb, nicht die
OpenClaw-Runtime.

## 1. Verbindliches Zielbild

Nexus wird die zentrale, agent-first Mission-Control-Oberfläche für alle
alltäglichen Steuerungs-, Überwachungs- und Freigabeaufgaben. Die technische
Ausführung bleibt bewusst eindeutig:

```text
Browser / Owner
    -> Nexus UI
    -> Nexus API (Auth, RBAC, Policies, Approvals, Audit)
    -> typisierte OpenClaw-Gateway-Fassade
    -> OpenClaw Gateway (Agents, Sessions, Tools, Cron, Channels, Nodes, Routing)
    -> OpenAI (primärer Modellprovider)
```

Zusätzlich greifen OpenClaw-Agenten über die kontrollierte Nexus-MCP- oder
TaskBridge-Schnittstelle auf Nexus-eigene Projekte und Tasks zu.

Verbindliche Architekturregeln:

- Nexus ruft OpenAI **nicht direkt** auf und speichert keinen OpenAI-API-Schlüssel.
- OpenClaw ist der verpflichtende Runtime- und Gateway-Pfad für jede
  Modell-/Agentenausführung.
- OpenAI wird innerhalb von OpenClaw als primärer Provider konfiguriert.
- Exakte Modellreferenzen werden als explizite `provider/model`-Policies in
  OpenClaw verwaltet; das konkrete Modell bleibt eine Betriebsentscheidung und
  wird nicht dauerhaft in der Nexus-Domäne fest verdrahtet.
- Browser-Clients sprechen weder OpenClaw noch OpenAI direkt an.
- Nexus bildet keine zweite, konkurrierende Agentenruntime und keinen zweiten
  Session Store.
- Die OpenClaw-Oberfläche darf für Recovery und Break-glass-Betrieb verfügbar
  bleiben, darf aber für den normalen Arbeitsalltag nicht erforderlich sein.

## 2. System-of-Record und Ownership

| Bereich | Autoritative Quelle | Nexus-Aufgabe |
|---|---|---|
| Nutzer, Rollen, RBAC | Nexus | Authentifizieren, autorisieren, verwalten |
| Projekte und fachliche Tasks | Nexus | CRUD, Zustände, Abhängigkeiten, Delegation |
| Menschliche Entscheidungen und Freigaben | Nexus | Policy, Entscheidung, Audit, Eskalation |
| Produktziele, KPIs und Budgets | Nexus | Planen, überwachen, mit Runs korrelieren |
| OpenClaw-Agentenkonfiguration | OpenClaw | Sicher lesen und über typisierte Mutationen steuern |
| Modelle, Provider und Auth-Profile | OpenClaw | Status, Policies und sichere Secret-Referenzen bedienen |
| Sessions und Subagent-Runs | OpenClaw | Suchen, anzeigen, starten und kontrollieren |
| Tool-Katalog und Runtime-Tool-Policy | OpenClaw | Effektive Rechte darstellen und kontrolliert ändern |
| Cron Jobs und Run-Historie | OpenClaw | Vollständigen Lifecycle in Nexus bedienen |
| Channels, Nodes und Gatewayzustand | OpenClaw | Betriebsansicht und kontrollierte Aktionen anbieten |
| Modellinferenz und Provider-Usage | OpenAI über OpenClaw | Kosten/Usage über OpenClaw korrelieren und auswerten |
| Control-Plane-Audit | Nexus | Jede Mutation, Freigabe und Korrelation dauerhaft protokollieren |

Nexus darf Projektionen und zeitlich begrenzte Read Models für schnelle
Oberflächen speichern. Jede Projektion zeigt Quelle, Zeitpunkt und Freshness;
bei Konflikten bleibt OpenClaw für Runtimezustand autoritativ.

## 3. Aktuelle Basis

Bereits vorhanden und weiterzuverwenden:

- Vue-/Pinia-Frontend mit 21 benannten Seiten (Login plus 20 authentifizierte
  Views) und einheitlicher
  Mission-Control-Designsprache
- ASP.NET-Core-API, PostgreSQL, JWT-/Refresh-Session-Grundlage
- `IAgentRuntime` mit `OpenClawRuntime` als einzig registriertem Runtime-Adapter
- Protocol-v4-`IGatewayConnector` für Challenge/Hello, RPC-Korrelation,
  Capabilities, Scopes, Events, Timeouts, Reconnect und Versionspinning
- ein owner-only Attach-&-Adopt-Flow mit begrenzter Discovery, Probe,
  read-only Pairing, einem persistierten `primary`-Profil, Adoption ohne
  Runtime-Datenkopie und separatem Management-Scope-Upgrade
- browser-sicherer `IOpenClawControlService` für Tasks, Sessions, Approvals,
  Cron, Activity, Models und Agents
- live Agent-Inventar über `agents.list`, erlaubte Bootstrap-Dateien über
  `agents.files.*`, read-only Workspace-Browsing und schema-basiertes
  `config.*` mit Hashkonflikt, Diff und Read-back-Verifikation
- vollständiger typisierter Cron-Kern-Lifecycle mit Liste, Detail, Create,
  Edit, Enable/Disable, Delete, Sofortlauf und paginierter Run-Historie
- redigierter `models.authStatus` und der offizielle, in Nexus gerenderte
  `wizard.*`-Flow
- funktionale Mutationen für Task-Cancel, Session-Abort, Session-Model,
  Approval-Entscheidung, Agent-Dateien, Config und Cron
- funktionale Task-Domäne mit Parent-/Child-Tasks, Handoffs und MCP-/Bridge-Zugriff
- echte Arbeitsflächen für `/runs`, `/models` und `/activity`
- OpenClaw-gebundene Dashboard-, Agent-, Calendar-, Notification-, Security-
  und Settings-Flächen mit ehrlichen Loading-/Empty-/Error-Zuständen

Noch nicht ausreichend:

- OpenClaw `2026.7.1` registriert noch keine offiziell unterstützte externe
  Nexus-/Generic-Operator-Client-ID. Nexus imitiert keine interne
  Gateway-Identität; der produktive Connector bleibt deshalb blockiert.
- Reales Remote-Pairing, bewusster Scope-Upgrade und Live-Schreibtests für
  Agent-Dateien, Config und Cron an eindeutig benannten Testobjekten sind noch
  nicht abgenommen.
- OpenAI ist noch nicht durch einen realen, wiederholbaren
  `Nexus -> OpenClaw -> OpenAI -> Nexus`-Smoke als Primärprovider belegt.
- Runstart, Resume, Retry, Branching, Subagenten, Tools, Channels und Nodes sind
  nicht durchgängig bedienbar.
- Agent-Lifecycle-Aktionen wie Create, Enable/Disable, Restart und Delete fehlen
  noch; beliebige Workspace-Dateien bleiben mangels sicherem OpenClaw-Write-RPC
  absichtlich read-only.
- Der lokale Idempotency-Ledger bleibt ein Single-Writer-Vertrag und deckt noch
  nicht jede zukünftige Gateway-Mutation ab.
- Security-, Audit-, E2E- und Eval-Gates reichen für eine produktive
  Agenten-Control-Plane noch nicht aus.

Produktionscheckpoint v0.2.59 vom 2026-07-31:

- Gitea Run 362 hat Commit
  `144edf58fe5928a3e04816f4435ea574d64211a1` mit grünen Backend-, Frontend-,
  Security- und Deploymentjobs ausgeliefert.
- PostgreSQL und die HTTP-Runtime zu Baos OpenClaw sind auf Produktion stabil
  gesund. Docker-DNS verwendet `openclaw-gateway:18789`; der Release-Gate
  akzeptiert keinen `Degraded`-Healthstatus mehr.
- 363 Backendtests und 25 Browsertests bestehen in CI. Fünf explizite
  Docker-/Toxiproxy-Integrationsfälle bleiben ohne CI-Opt-in sichtbar
  übersprungen.
- Auth-Grenzen, SPA-Routing, Security-Header und der korrigierte Loginfehler
  sind live geprüft. Credentialed Owner-Flows, Gateway-Pairing,
  OpenClaw-Schreibvorgänge und der OpenAI-End-to-End-Run bleiben offen.

Die vollständige Evidenz und der daraus abgeleitete Plan stehen in
[Production release v0.2.59](audits/2026-07-31/production-release-v0.2.59/PRODUCTION_VALIDATION_AND_NEXT_PLAN.md).

Stabilitätscheckpoint v0.2.60 (Release Candidate) vom 2026-07-31:

- `/health/live`, `/health/ready` und `/health` trennen Prozesszustand,
  PostgreSQL-Readiness und vollständige OpenClaw-Diagnose. Deploy und Rollback
  verwenden dieselben Gates; ein OpenClaw-Ausfall hält die Recovery-Oberfläche
  erreichbar.
- Die ungenutzte Antiforgery-Route ist entfernt. Refresh und Logout behalten
  das strikte Secure-/HttpOnly-Cookie und weisen explizite Cross-Site-Browser-
  Aufrufe anhand von `Origin` und `Sec-Fetch-Site` ab.
- OpenAPI beschreibt den gemeinsamen `ProblemDetails`-Vertrag einschließlich
  stabilem Code und Trace-ID. Alle 20 authentifizierten Views verwenden die
  gemeinsame Loading-/Empty-/Error-/Offline-/Stale-/Partial-Schicht und
  erhalten sichtbare Daten bei Background-Refresh.
- `global.json`, `VERSION`-Parität, OCI-Provenienz, Browsertelemetrie-Schalter,
  High/Critical-Abhängigkeitsgates, checksum-verifiziertes Gitleaks und ein
  verpflichtender PostgreSQL-/Toxiproxy-CI-Job bilden den neuen Releasevertrag.
- Lokal bestehen 383 nicht-containerisierte Backendtests, 42 Frontendtests,
  Typecheck, Produktionsbuild und 26 kontrollierte Playwright-Tests. Die fünf
  Containerfälle sind lokal mangels Docker übersprungen und müssen im Linux-CI
  mit null Skips bestehen. Credentialed Produktion, Task-Board-Last und echte
  OpenClaw-Schreibpfade bleiben eigene Gates.

Die genaue Implementierungs- und Evidenzgrenze steht in
[Stability v0.2.60](audits/2026-07-31/stability-v0.2.60/IMPLEMENTATION_AND_ACCEPTANCE.md).

## 4. Prioritätsdefinition

- **P0:** Blockiert sicheren End-to-End-Betrieb oder das Kernversprechen
  „alles in Nexus steuerbar“.
- **P1:** Wird für den vollständigen täglichen Agentenbetrieb benötigt.
- **P2:** Erhöht Plattformreife, Skalierung, Komfort oder Governance.
- **P3:** Strategische Erweiterung nach belegter Kernreife.

Ein Meilenstein gilt nur dann als abgeschlossen, wenn Implementierung,
negative Tests, Bediennachweis, Fehlerzustände, Audit und Dokumentation
gemeinsam fertig sind.

## 5. Meilensteine

### M0 — Architektur- und Dokumentationsvertrag

**Priorität:** P0
**Ergebnis:** Alle Beteiligten bauen gegen dieselbe Zielarchitektur.

- [x] Verbindlichen Pfad `Nexus -> OpenClaw -> OpenAI` dokumentieren.
- [x] Runtime-, Provider- und Domänen-Ownership trennen.
- [x] Direkte OpenAI-Anbindung in Nexus explizit ausschließen.
- [x] Seiten- und Capability-Evaluation auf das korrigierte Zielbild abstimmen.
- [ ] Architekturentscheidungen als ADRs für Gatewaygrenze, Secret Ownership,
  Session Ownership und Audit/Korrelation ergänzen.
- [ ] Begriffe `Task`, `Run`, `Session`, `Subagent`, `Approval` und `Artifact`
  als gemeinsames Glossar festschreiben.

**Abnahme:** README, Zielvertrag, Evaluation, Roadmap und Obsidian-Mirror
widersprechen sich nicht.

### M1 — Vertrauensgrenze und OpenAI über OpenClaw

**Priorität:** P0
**Ergebnis:** Ein echter, sicherer Nexus-Auftrag wird über OpenClaw mit OpenAI
ausgeführt und ist Ende-zu-Ende nachweisbar.

Security:

- Authenticated-by-default für die API erzwingen.
- Benutzer-, Service- und Agentenidentitäten stark trennen und
  caller-kontrollierte Header niemals als alleinigen Nachweis akzeptieren.
- Gatewayzugriff mit kleinstmöglichen Operator-Scopes aufteilen:
  read, write, approvals und admin nur dort, wo erforderlich.
- Credential-artige Literale rotieren, aus Arbeitsbaum und gegebenenfalls
  Historie entfernen sowie Secret-Scanning als Gate ergänzen.
- Gatewayversion pinnen oder als explizit kompatiblen Bereich validieren.
- Transport, Reconnect, Timeout, Retry und Circuit-Breaker-Verhalten definieren.

OpenAI-Konfiguration in OpenClaw:

- OpenAI-Credentials ausschließlich in OpenClaw über Umgebungsvariable,
  Secret Provider oder sichere Auth-Profile verwalten.
- Primärmodell und erlaubte `openai/...`-Modelle explizit in OpenClaw setzen.
- Rollenbezogene Modellpolitik, Aliase, optionale Fallbacks, Limits und Budgets
  definieren.
- Nexus zeigt Verbindungsstatus, Provider, Modellpolicy, letzte Prüfung und
  Fehler an, aber niemals Secretwerte.
- Ein Live-Smoke-Test belegt:
  `Nexus -> OpenClaw session -> OpenAI model -> OpenClaw result -> Nexus`.
- Audit und Telemetrie belegen den tatsächlich verwendeten Provider und das
  Modell, ohne Prompts, personenbezogene Daten oder Secrets unnötig zu loggen.

**Checkpoint 2026-07-30:** Authenticated-by-default, Device-Key/-Token-
Persistenz, Endpoint-/TLS-Bindung, read-only-first Setup, Capability-Prüfung,
bewusster Admin-Scope-Upgrade und secret-sichere Modell-Authstatus-Projektion
sind lokal umgesetzt. Der Connector verwendet keine reservierte interne
OpenClaw-Identität. Offen bleiben die offiziell unterstützte externe
Nexus-/Generic-Client-ID, reales Pairing und Scope-Upgrade sowie der
End-to-End-Nachweis mit OpenAI.

**Abnahme:** Kein Netzwerkpfad von Nexus zu OpenAI ist nötig; ein realer
OpenAI-Lauf über OpenClaw ist wiederholbar grün und ein ungültiges oder
unberechtigtes Gatewaykommando scheitert sichtbar und sicher.

### M2 — Typisierte OpenClaw Control Plane

**Priorität:** P0
**Ergebnis:** Nexus kann OpenClaw sicher erweitern, ohne rohe RPC-Aufrufe in
Views oder Domänendiensten zu verteilen.

- Den generischen Gatewayclient hinter domänenspezifischen Verträgen kapseln:
  - `IOpenClawGatewayReadClient`
  - `IOpenClawGatewayControlClient`
  - Sessions/Run Service
  - Agent Service
  - Model/Auth-Profile Service
  - Tool/Approval Service
  - Cron Service
  - Channel Service
  - Node Service
  - Config/Recovery Service
- `InvokeToolAsync` als private Low-Level-Implementierung behandeln.
- Gateway-Schema und path-scoped Config-Schema entdecken und vor Mutationen
  validieren.
- Pro Operation erforderliche Scope, Risiko, Approval und Auditpayload
  deklarativ hinterlegen.
- Jede Mutation erhält Idempotency Key, Correlation ID, Actor, Target,
  erwartete Version und nachvollziehbares Ergebnis.
- Optimistische Versionsprüfung für Config-Mutationen und klaren Konfliktflow
  ergänzen.
- Read Models mit `source`, `observedAt`, `staleAfter` und Reconnectzustand
  versehen.
- Fehler nicht in leere Listen umwandeln; offline, unauthorized, stale,
  incompatible und partial müssen unterscheidbar sein.

**Checkpoint 2026-07-30:** `IGatewayConnector`, `IOpenClawControlService` und
separate Setup-, Agent-Configuration-, Wizard- und Run-Services kapseln den
verwendeten RPC-Umfang. Read Models tragen State, Recovery und
Beobachtungszeit; Methoden-, Scope-, Versions- und Hashfehler bleiben
unterscheidbar. Agent-Dateien, Config und Cron verwenden Idempotenz,
Correlation, Audit und optimistische Hashprüfung. Offen bleiben getrennte
Fachverträge für Tools, Channels und Nodes sowie ein transaktionaler
Multi-Replica-Ledger.

**Abnahme:** Kein Frontend- oder Domänencode ruft generische OpenClaw-Methoden
direkt auf; alle privilegierten Mutationen besitzen Contract-, Auth-, Negativ-
und Audit-Tests.

### M3 — Universeller agent-first Einstieg, Sessions und Runs

**Priorität:** P0/P1
**Ergebnis:** Ziele werden von jeder Seite aus an Iris übergeben; Ausführungen
bleiben über Reloads hinweg auffindbar und steuerbar.

- Globale Command Bar und alle sichtbaren „Ask Iris“-Einstiege funktional
  vereinheitlichen.
- Kontext der aktuellen Route und ausgewählter Objekte explizit anzeigen und
  vor dem Senden editierbar machen.
- Iris-Chat standardmäßig als Modal/Drawer öffnen und Streaming,
  Stop, Retry sowie nachvollziehbare Fehler bieten.
- Session Explorer mit Liste, Suche, Filtern, Verlauf, Freshness und
  Detailansicht liefern.
- Session starten, senden, verzweigen, archivieren und — soweit OpenClaw es
  unterstützt — zurücksetzen oder kompaktieren.
- OpenClaw-Session und Subagent-Task mit Nexus-Projekt, Task, Owner und
  Control-Audit korrelieren.
- Subagenten starten, Hierarchie anzeigen, Status/Logs verfolgen, abbrechen
  und Ergebnis übernehmen.
- Dashboard-Live-Orchestrierung auf autoritative Session-/Run-Ereignisse
  umstellen; keine rein aus Text abgeleiteten Betriebszustände.
- Reload-/Reconnect-Recovery und Deep Links zu Session, Agent, Task und
  Artifact ergänzen.

**Abnahme:** Ein Owner kann ausschließlich in Nexus einen Auftrag formulieren,
Subagenten beobachten, einen riskanten Schritt freigeben, den Lauf stoppen und
nach einem Reload wiederfinden.

### M4 — Agenten, Modelle, Tools und Approvals

**Priorität:** P1
**Ergebnis:** Die zentralen Runtime-Ressourcen sind ohne OpenClaw-UI sicher
bedienbar.

Agenten:

- Erstellen oder aus erlaubten Vorlagen importieren.
- Aktivieren, deaktivieren, neu starten und kontrolliert entfernen.
- Rolle, Workspace, Modellpolicy, Capability-Profil, Tools und Budget anzeigen.
- Drift zwischen gewünschter Policy und OpenClaw-Istzustand erkennen.

Modelle und Provider:

- OpenAI-Verbindungs- und Auth-Profilstatus anzeigen.
- Primärmodell, rollenbezogene Aliase, Allowlist und Fallbacks über OpenClaw
  verwalten.
- Modellkatalog, Fähigkeiten, Limits und gemessene Qualität darstellen.
- Policyänderungen mit Diff, Version, Approval und Rollback absichern.
- Budget- und Usage-Grenzen mit Warnung und kontrolliertem Fallback ergänzen.

Tools und Freigaben:

- OpenClaw-Tool-Katalog, Schemas und effektive Toolrechte darstellen.
- Toolprofile sowie Allow-/Deny-Regeln global und pro Agent steuern.
- Approval Inbox für Exec, Plugin, Config, externe Datenweitergabe und
  irreversible Aktionen liefern.
- Zeitlimit, Begründung, Entscheider, Policyversion und Ergebnis jeder
  Freigabe protokollieren.
- Tool-Ausgaben als nicht vertrauenswürdige Daten behandeln und
  Prompt-Injection-/Exfiltrationsgrenzen sichtbar machen.

**Checkpoint 2026-07-30:** Agent-Inventar und Bootstrap-Dateien stammen live
aus OpenClaw; erlaubte Dateien sind mit Expected Hash und Read-back editierbar,
zusätzliche Workspace-Dateien read-only. Standing Orders werden kontrolliert in
`AGENTS.md` gepflegt. `/models` zeigt den Live-Katalog und ausschließlich den
redigierten `models.authStatus`. Agent-Lifecycle, Tool-Katalog/-Policies,
Modell-Policy-Mutationen, Budgets und Evals bleiben offen.

**Abnahme:** Ein Modell-, Tool- oder Agentenwechsel ist ohne rohe
`openclaw.json`-Bearbeitung möglich, lässt sich zurückverfolgen und kann keine
Secrets offenlegen.

### M5 — Scheduler und Automationen

**Priorität:** P1
**Ergebnis:** Alle regelmäßigen Agentenabläufe sind in Nexus plan- und
kontrollierbar.

- Cron Jobs auflisten, suchen, erstellen, kopieren und bearbeiten.
- Aktivieren, pausieren, fortsetzen, sofort ausführen und entfernen.
- Zeitzone, Session Mode, Zielagent, Payload, Delivery/Webhook, Owner und
  Projektbezug konfigurieren.
- Nächsten Lauf, letzte Ausführung, Run-Historie, Dauer, Fehler und Retry
  darstellen.
- Vorlagen für wiederkehrende Reports, Wartung, Recherche und Incident Checks
  anbieten.
- Admin-relevante Mutationen über Approval und Scope Gate absichern.
- Retry-/Backoff-, Missed-run- und Alerting-Policies definieren.

**Checkpoint 2026-07-30:** Liste, Detail, Create, Edit, Enable/Disable, Delete,
Sofortlauf und paginierte OpenClaw-Run-Historie sind typisiert umgesetzt.
Mutationen benötigen Owner, lokale Managementfreigabe, `operator.admin`,
Idempotency Key und bei vorhandenen Jobs den aktuellen Ressourcenhash. Ein
Sofortlauf wird nur als eingereiht gemeldet; der tatsächliche Ausgang stammt
aus `cron.runs`.
Command-Payloads und `on-exit` bleiben durch `AllowCommandCron=false`
gesperrt. Offen bleiben Live-Schreibabnahme, Copy/Templates und umfassende
Retry-/Missed-run-/Alerting-Policies.

**Abnahme:** Ein Scheduler-Workflow kann vollständig in Nexus angelegt,
probeweise ausgeführt, pausiert, diagnostiziert und entfernt werden.

### M6 — Knowledge, Workspaces und Artifacts

**Priorität:** P1
**Ergebnis:** Agentenwissen und Outputs sind kontrollierbar, versioniert und
mit Arbeit verknüpft.

- Memory-Einträge erstellen, bearbeiten, archivieren und löschen.
- Dokumente hochladen, importieren, schreiben, versionieren und freigeben.
- Quelle, Owner, Scope, Freshness, Retention und Ingestionstatus anzeigen.
- Retrieval-Tests und zitierbare Provenienz ergänzen.
- Workspace-Dateien über erlaubte Roots browsen und bearbeiten.
- Schreibzugriffe mit Diff, Allowlist, Backup, Validierung und Approval
  absichern.
- Artifacts hochladen, anzeigen, herunterladen, versionieren und mit Session,
  Task, Projekt sowie Incident verknüpfen.
- Sensible Daten klassifizieren und Export-/Retention-Policies anwenden.

**Checkpoint 2026-07-30:** Die Standard-Agentdateien werden über
`agents.files.*` verwaltet. Weitere Dateien wie `DREAMS.md` oder
`memory/YYYY-MM-DD.md` werden über `agents.workspace.*` angezeigt und bleiben
mangels sicherem beliebigem Workspace-Write-RPC read-only. Die eigenständigen
Nexus-Flächen für Memory, Docs, Ingestion, Versionierung und Artifacts sind
damit noch nicht abgeschlossen.

**Abnahme:** Ein Agent kann aus Nexus freigegebenes Wissen nutzen, ein Artifact
erzeugen und dessen Herkunft bis zum Auftrag und Tool-Aufruf nachvollziehbar
machen.

### M7 — Operations, Governance und Recovery

**Priorität:** P1
**Ergebnis:** Mission Control steuert nicht nur Agenten, sondern auch den
sicheren Betriebsalltag.

- Zentrale Approval Inbox mit Filtern, SLA, Eskalation und Batch-Entscheidung
  für ausschließlich risikoarme, gleichartige Fälle.
- Benachrichtigungsregeln, Kanäle, Snooze, Acknowledge und Quiet Hours.
- Incidents erstellen, bestätigen, zuweisen, eskalieren, beheben, schließen
  und als Postmortem dokumentieren.
- Session-, Task-, Tool- und Providerereignisse mit Incidents korrelieren.
- Security Center mit tatsächlicher Policy-/Auth-Lage, Remediation und
  Evidenz statt reiner Konfigurationsanzeige.
- Nutzer-Sessions, Geräte, 2FA/Passkeys, Schlüsselrotation und Recovery Codes.
- Autoritativer Audit-/Event-Stream mit Actor, Korrelation, Diff, Suche,
  Export und Retention.
- Gateway-Recovery mit Version, Health, kontrolliertem Reload, Backup,
  Rollback und Break-glass-Prozedur.

**Abnahme:** Kritische Fehler und riskante Aktionen können in Nexus erkannt,
freigegeben, behoben und vollständig auditiert werden.

### M8 — Channels, Connectors, Nodes und Parität

**Priorität:** P2
**Ergebnis:** Auch OpenClaw-nahe Infrastruktur muss im Alltag nicht separat
bedient werden.

- Channels verbinden, Status/Capabilities prüfen, Logs filtern und
  kontrolliert trennen.
- Connectorrechte, Datenfreigaben und Approval Policies verwalten.
- Nodes/Hosts inventarisieren, pairen, Health und Capabilities anzeigen.
- Node-Aktionen erlaubnis- und approval-basiert ausführen.
- Gateway-Konfiguration über Live-Schema, strukturierte Formulare und Diff
  pflegen; keine unvalidierte Raw-JSON-Konsole als Hauptweg.
- Updates und Reloads mit Kompatibilitätsprüfung, Wartungsmodus, Backup und
  Rollback steuern.
- Optional Voice-, Media- und Mobile/PWA-Oberflächen ergänzen, sobald die
  Control-Plane-Gates stabil sind.

**Checkpoint 2026-07-30:** Settings enthält einen schema-basierten
OpenClaw-Configeditor mit `config.schema.lookup`, `config.get`,
`config.patch`, `baseHash`, Diff-Vorschau und `replacePaths`. Der offizielle
`wizard.*`-Flow wird sicher gerendert, sobald die verbundene Instanz ihn mit
Managementfreigabe und `operator.admin` bewirbt. Channels, Nodes,
Update-/Reload- und Recovery-Parität bleiben offen.

**Abnahme:** Die dokumentierte tägliche OpenClaw-UI-Checkliste besitzt für
jeden normalen Vorgang einen sicheren Nexus-Workflow.

### M9 — Observability, Kosten, Evals und Release-Reife

**Priorität:** P2
**Ergebnis:** Qualität, Kosten und Betriebssicherheit sind messbar und
regressionsfest.

- Autoritative Provider-, Modell-, Token-, Kosten- und Latenzdaten erfassen.
- Trace-/Run-Explorer für Session-, Tool-, Approval-, Artifact- und
  Fehlerereignisse liefern.
- Budgets und Alerts pro Projekt, Agent, Modell und Zeitraum.
- Eval-Datasets für Instruction Following, funktionale Korrektheit,
  Tool-Auswahl und Argumentgenauigkeit pflegen.
- Prompt-, Agenten-, Modell- und Policyversionen in Vergleichsläufen messen.
- Qualitäts-, Kosten-, Security- und Latenzschwellen als Release Gates.
- E2E-Tests über Browser, Nexus, OpenClaw, OpenAI und PostgreSQL.
- Alle Routen auf Auth, Loading, Empty, Error, Keyboard und
  375/768/1024/1440/1920 px testen.
- Last-, Reconnect-, Timeout-, Queue-, Recovery- und Chaos-Szenarien prüfen.
- Runbooks, Backup/Restore und Rollback regelmäßig als Game Day testen.

**Checkpoint 2026-07-31:** Das v0.2.60-Stabilitätsfundament implementiert
separate Readiness, einen generierten Fehlervertrag, gemeinsame UI-Recovery,
ein SDK-/Versionsgate, Supply-Chain-Scans und verpflichtende Containerverträge.
Der kontrollierte Browserlauf deckt alle 20 authentifizierten Views und fünf
Breiten ab. Offen bleiben der grüne Linux-/Docker-Run, credentialed
Produktionsprüfung, der 1.000/10.000-Task-Board-Lastnachweis sowie reale
OpenClaw-/OpenAI-End-to-End-Evidenz.

**Abnahme:** Ein Release ist nur möglich, wenn technische Checks und ein
repräsentativer realer Agenten-Workflow gemeinsam grün sind.

### M10 — Strategische agent-first Erweiterungen

**Priorität:** P3
**Ergebnis:** Nach belegter Kernreife wird Nexus vom Cockpit zum proaktiven
Operationssystem.

- Ziel- und Outcome-Management mit Agentenplänen, KPIs und Abbruchkriterien.
- Wiederverwendbare Agenten-, Workflow- und Projekt-Playbooks.
- Simulation/Dry Run für riskante oder kostenintensive Ausführungen.
- Policy-basierte Auto-Approvals für eng begrenzte, reversible Aktionen.
- Proaktive Opportunity-, Risk- und Drift-Erkennung mit menschlicher
  Bestätigung.
- Multi-Workspace-/Teamgrenzen und delegierte Administration.
- Agentenqualitäts-SLOs, automatische Regressionserkennung und
  modellabhängige Routingoptimierung.

## 6. Auswirkungen auf die 18 bestehenden Seitenfamilien

| Route | Zielrolle | Verbindliche Verbesserungen | Meilenstein |
|---|---|---|---|
| `/login` | Sicherer Zugang | Recovery, Return-to-Route, 2FA/Passkeys, Geräte/Sessions | M1, M7 |
| `/dashboard` | Mission Overview | echte Command Bar, autoritative Run-Hierarchie, Queue, Providerstatus, Usage, Fehler/Recovery | M1, M3, M9 |
| `/memory` | Wissensspeicher | CRUD, Scope, Provenienz, Freshness, Retention, Retrieval-Evals | M6, M9 |
| `/docs` | Knowledge Ingestion | Upload/Authoring, Import/Sync, Versionen, Zitate, Freigaben | M6 |
| `/agents/:id` | Agent Cockpit | live Bootstrap-Dateien, Standing Orders und read-only Workspace vorhanden; Lifecycle, Sessions, Subagenten, Tools, Modellpolicy, Budget, Evals offen | M3, M4, M9 |
| `/security` | Security Center | echte Auth-/Policylage, Findings, Remediation, Rotation, Sessions, Audit | M1, M7 |
| `/incidents` | Incident Operations | Create/Ack/Assign, Timeline, Run-Bezug, Remediation, Resolve, Postmortem | M7 |
| `/calendar` | Automation Scheduler | Cron-CRUD, Enable/Disable, Sofortlauf und History vorhanden; Live-Abnahme, Templates, Retry-Policy und Delivery-Härtung offen | M5 |
| `/projects` | Portfolio | Ziele, Team, Runs, Tasks, Artifacts, Budget, Health, Automationen | M3, M6, M9 |
| `/projects/:id` | Project Control | Delegation, Runstart, KPIs, Team, Timeline, Budget, Playbooks | M3, M6, M10 |
| `/tasks` | Agent Work Queue | Run-/Approval-Bezug, Dependencies, Bulk, Retry/Resume/Cancel, ehrliche Fehler | M3, M7 |
| `/tasks/:id` | Task Control | Session/Run, Tools, Approvals, Artifacts, Abhängigkeiten, Replay | M3, M6 |
| `/agents` | Runtime Workforce | Live-Inventar vorhanden; Create/Import, Enable/Disable/Restart, Capabilities, Permissions, Last und Kosten offen | M4, M9 |
| `/models` | OpenAI Policy via OpenClaw | redigierter Authstatus vorhanden; Primärmodell, Allowlist, Aliase, Fallbacks, Limits und Tests offen | M1, M4 |
| `/activity` | Audit/Event Stream | autoritative Events, Correlation ID, Actor, Diff, Suche, Export, Retention | M2, M7 |
| `/runs` | Run Control | Start/Resume/Retry/Branch, Deep Links, Trace, Tools, Artifacts und dauerhafte Korrelation | M2, M3, M7 |
| `/notifications` | Action Inbox | Loading/Error, Ack/Snooze, Preferences, Routing, Approval-/Incident-Aktionen | M7 |
| `/settings` | Control-Plane Setup | Attach & Adopt, Management-Gate, Configschema und Wizard vorhanden; offizielle Client-ID, Live-Pairing, Tools, Approvals und Retention offen | M1, M4, M7, M8 |

Seit dem 2026-07-31-Checkpoint liefern die fachlichen Task-, Projekt-,
Notification-, Cron-, Config-, Approval-, Session- und Agent-Datei-Mutationen
ein gemeinsames `OperationResultDto`. Das globale Ergebnisfenster verlinkt
Primär- und Folgeobjekte; Task Detail, Run Control, Calendar, Agent Detail,
Activity, Notifications und Settings konsumieren die jeweilige Deep-Link-
Auswahl. Damit ist die querschnittliche Ergebnisnavigation umgesetzt. Offen
bleiben die in der Tabelle genannten fachlichen Funktionen und die externen
Live-/Lastgates, nicht ein weiterer paralleler Frontend-Ergebnisvertrag.

Iris Chat ist kein eigener Route mehr. Er bleibt als persistenter, kontextueller
Dashboard-Dialog und globales Ziel für „Ask Iris“.

## 7. Vorgeschlagene neue Arbeitsflächen

Diese Routen sind Produktvorschläge. Sie dürfen erst in Navigation oder
Deep Links erscheinen, wenn Route und funktionsfähiges Ziel registriert sind.

| Vorgeschlagene Route | Zweck | Alternative bei kleinerem Scope |
|---|---|---|
| `/runs/:id` | dauerhafte Deep-Link-Ansicht eines korrelierten Laufs (umgesetzt) | `/agents/:id?session=...` |
| `/tools` | Katalog, Schemas, effektive Rechte und Policies | Tab in Agent Detail |
| `/approvals` | zentrale menschliche Freigaben | Notifications-Filter als erster Slice |
| `/artifacts` | Outputs, Dateien, Herkunft und Versionen | Project-/Task-Tab |
| `/channels` | Channelstatus, Capabilities und Logs | Settings-Tab |
| `/nodes` | Hosts, Pairing, Health und erlaubte Aktionen | Settings-Tab |
| `/evals` | Datensätze, Vergleiche und Qualitätsgates | Models-Tab |

`/runs` und der dauerhafte `/runs/:id`-Pfad sind umgesetzt. Approvals können bis
zur benötigten Inbox-Tiefe in Run Control und Notifications bleiben. Tools,
Channels und Nodes können initial als Tabs starten, solange Navigation und
Informationsarchitektur nicht überladen werden.

## 8. Querschnittsabhängigkeiten

```mermaid
flowchart TD
    M0["M0 Architekturvertrag"] --> M1["M1 Trust + OpenAI über OpenClaw"]
    M1 --> M2["M2 Typisierte Gateway Control Plane"]
    M2 --> M3["M3 Sessions, Runs, Iris"]
    M2 --> M4["M4 Agents, Models, Tools, Approvals"]
    M2 --> M5["M5 Scheduler"]
    M3 --> M6["M6 Knowledge + Artifacts"]
    M3 --> M7["M7 Operations + Governance"]
    M4 --> M7
    M5 --> M7
    M6 --> M8["M8 Ecosystem-Parität"]
    M7 --> M8
    M3 --> M9["M9 Observability + Evals"]
    M4 --> M9
    M5 --> M9
    M8 --> M10["M10 Strategische Erweiterungen"]
    M9 --> M10
```

M3 bis M5 dürfen vertikal in kleine Slices zerlegt werden. Sie dürfen aber
nicht die M1-/M2-Vertrauensgrenze umgehen.

## 9. Nächster empfohlener Implementierungsslice

**Slice: „Official external identity and controlled live acceptance“**

1. Upstream eine offiziell unterstützte externe `nexus`- oder generische
   Operator-Client-ID verwenden und Nexus auf die erste unterstützende
   OpenClaw-Version pinnen; keine reservierte interne Identität imitieren.
2. Auf Baos ausdrücklich freigegebener OpenClaw-Instanz read-only verbinden,
   die konkrete Pairing-Request-ID freigeben lassen und Agent-/Cron-Inventar
   gegen den erwarteten Bestand abgleichen, ohne Runtime-Daten zu kopieren.
3. Den bewussten Admin-Scope-Upgrade separat pairen und Endpoint-, Device-,
   TLS-, Scope- und Capability-Bindung im Security Center belegen.
4. Ausschließlich an eindeutig benannten Testobjekten je einen
   Hashkonflikt-/Read-back-Test für Agent-Datei und Config sowie Create/Edit/
   Run/History/Delete für Cron durchführen. Andere Ressourcen bleiben
   unangetastet.
5. OpenAI ausschließlich in OpenClaw als Primärprovider für Iris konfigurieren
   und einen echten, dauerhaft korrelierten
   `Nexus -> OpenClaw -> OpenAI -> Nexus`-Run ausführen.
6. Provider-/Modellreferenz, Events, Stop/Retry, Reload-Recovery, Audit und
   Negativfälle ohne Prompt-, Delivery- oder Secret-Leak belegen.

Dieser Slice löst den externen Identitätsblocker und liefert den ersten
vollständigen Beweis, dass Attach & Adopt sowie ein normaler agent-first
Arbeitsablauf ohne Wechsel in die OpenClaw-Oberfläche sicher funktionieren.

## 10. Definition of Done für „kein OpenClaw-Wechsel mehr“

Das Produktversprechen gilt erst als erfüllt, wenn:

1. ein Owner den vollständigen Ablauf
   `Absicht -> Plan -> Agent/Subagent -> Tool -> Approval -> Artifact -> Review`
   ausschließlich in Nexus bedienen kann;
2. OpenClaw für alle Runtimezustände autoritativ bleibt, während Nexus diese
   zuverlässig, aktuell und steuerbar projiziert;
3. jede Modellinferenz aus Nexus nachweislich über OpenClaw läuft und OpenAI
   dort der primäre Provider ist;
4. kein OpenAI-Secret in Browser, Nexus-Konfiguration, Datenbank oder Logs
   benötigt oder offengelegt wird;
5. alle normalen Agenten-, Session-, Tool-, Cron-, Modell-, Approval-,
   Knowledge-, Incident- und Recovery-Aufgaben Nexus-Workflows besitzen;
6. jede riskante Mutation Scope, Policy, Approval, Idempotenz und Audit besitzt;
7. Offline-, Partial-, Stale-, Unauthorized- und Incompatible-Zustände für den
   Operator verständlich und handlungsfähig sind;
8. reale E2E-, Security-, Eval-, Recovery-, Accessibility- und Responsive-Gates
   grün sind;
9. die OpenClaw-Oberfläche nur noch für dokumentierten Break-glass- oder
   Plattformentwicklungsbetrieb gebraucht wird.

## 11. Bewusste Nicht-Ziele

- Kein direkter OpenAI-Adapter oder OpenAI-Schlüssel in Nexus.
- Keine zweite Agentenruntime, kein zweiter OpenClaw-Session Store.
- Keine ungeprüfte Raw-Config-Konsole als primärer Verwaltungsweg.
- Keine direkte Browser-Gateway-Verbindung.
- Keine Navigation zu nicht registrierten oder leeren Routen.
- Kein kosmetisches „Control“-UI ohne wirksame Mutation, Fehlerfeedback und
  Audit.
- Keine komplette Kopie jeder OpenClaw-Entwickleroberfläche; Nexus bildet die
  Owner- und Operations-Workflows ab.

## 12. Primärquellen

OpenClaw:

- [Modelle und `provider/model`-Policies](https://docs.openclaw.ai/models)
- [Gateway-Protocol-v4-Vertrag](https://docs.openclaw.ai/gateway/protocol)
- [Gateway-Client und Geräteidentität](https://docs.openclaw.ai/gateway/clients)
- [Stable Client-ID-Registry `2026.7.1`](https://github.com/openclaw/openclaw/blob/v2026.7.1/packages/gateway-protocol/src/client-info.ts)
- [Operator-Scopes und Least Privilege](https://docs.openclaw.ai/gateway/operator-scopes)
- [Gateway-Konfiguration](https://docs.openclaw.ai/gateway/configuration)
- [Offizieller Setup-Wizard](https://docs.openclaw.ai/reference/wizard)
- [Background Tasks](https://docs.openclaw.ai/automation/tasks)
- [Cron-Operationen und erforderliche Scopes](https://docs.openclaw.ai/cli/cron)
- [Tools Invoke HTTP API](https://docs.openclaw.ai/gateway/tools-invoke-http-api)
- [Gateway Troubleshooting](https://docs.openclaw.ai/gateway/troubleshooting)

OpenAI:

- [API-Key-Sicherheit und Produktionsbetrieb](https://developers.openai.com/api/docs/guides/production-best-practices#api-keys)
- [Eval-Kriterien für einzelne Agenten](https://developers.openai.com/api/docs/guides/evaluation-best-practices#single-agent-architectures)