# Nexus v0.2.60 — Stabilität und Recovery

**Stand:** 2026-07-31

**Status:** In Produktion deployt; technische Releasegates grün, credentialed
Owner-Abnahme, Lastnachweis und produktive OpenClaw-Writes separat offen

**Scope:** Nexus-Repository und kontrollierte Browser-Fixtures. Keine
produktive OpenClaw-Mutation; Maxis Ressourcen lagen vollständig außerhalb des
Prüfbereichs.

## Ergebnis

Der erste Stabilitäts- und Fehlerabbau-Slice ist implementiert und deployt.
Nexus trennt jetzt Prozess-Liveness, Datenbank-Readiness und vollständige
Runtime-Diagnose,
liefert einen generierten gemeinsamen Fehlervertrag und zeigt auf allen 20
authentifizierten Views einheitliche Loading-, Empty-, Error-, Offline-, Stale-
und Partial-Zustände. Releaseversion, Containerprovenienz, Dependency- und
Secret-Scans sowie die echten PostgreSQL-/Toxiproxy-Verträge sind Teil der
CI-Freigabe.

Das ist noch keine vollständige authentifizierte Produktions- oder
OpenClaw-Abnahme. Der Owner-Audit, Task-Board-Lastnachweis und jeder produktive
OpenClaw-Schreibvorgang bleiben getrennte Gates.

## Implementierter Vertrag

### Health, Deployment und Version

- `GET /health/live` ist ein reiner Prozesscheck.
- `GET /health/ready` prüft ausschließlich Pflichtabhängigkeiten mit dem Tag
  `ready`; PostgreSQL-Ausfall liefert HTTP 503.
- `GET /health` bleibt die vollständige Diagnose. Ein OpenClaw-Ausfall ergibt
  `Degraded`, ohne die Nexus-Recovery-Oberfläche durch Readiness zu sperren.
- Der API-Container wird über `/health/ready` geprüft. Web wartet auf einen
  gesunden API-Container; API wartet auf gesundes PostgreSQL.
- Deployment prüft zuerst die lokale Container-Readiness, danach öffentliche
  Readiness und den vollständigen Runtimezustand. Rollback verwendet dieselben
  Gates und akzeptiert HTTP 404 für `/health/ready` nur bei einem sichtbaren
  Notfall-Rollback auf Versionen vor v0.2.60.
- `global.json` verlangt .NET `10.0.100` mit `latestFeature`-Roll-forward.
  `VERSION` ist die Releasequelle; Frontendpaket und OCI-Labels werden dagegen
  geprüft. Images tragen Version und exakten Git-SHA.

### Auth und Browsergrenze

- Die ungenutzte `/api/v1/auth/csrf`-Route und Antiforgery-Registrierung sind
  entfernt. Kein Client sendete das Token und keine Mutation validierte es.
- Das Refresh-Cookie bleibt `Secure`, `HttpOnly` und `SameSite=Strict`.
- Refresh und Logout weisen explizite Cross-Site-Browseraufrufe anhand von
  `Origin` und `Sec-Fetch-Site` ab. API-Clients ohne Browser-Provenienzheader
  benötigen weiterhin das gültige Cookie und unterliegen den normalen Limits.
- Login-, Refresh- und Rate-Limit-Fehler verwenden denselben strukturierten
  Problemvertrag.
- Nach einem fehlgeschlagenen Refresh leitet das Frontend genau einmal zum
  Login um und erhält das Rückkehrziel.
- Ein persistierter Refresh-Hash bleibt über eine neu erzeugte Serviceinstanz
  verwendbar und wird anschließend rotiert. Ein echter Containerneustart wird
  zusätzlich im produktionsnahen Releaseprofil geprüft.

### Gemeinsame Fehler- und Recovery-Schicht

Backendfehler verwenden `application/problem+json` mit:

- `code`, `status`, `title`, `detail`, `traceId`;
- optional `operationId`, `currentRevision`, `retryAfterSeconds`, `remaining`;
- den stabilen Codes `validation_failed`, `unauthenticated`, `forbidden`,
  `conflict`, `not_found`, `unsupported_capability`,
  `dependency_unavailable`, `timeout`, `rate_limited` und `internal_error`.

Durable Agent-Proposal-, Run- und andere Operationsendpunkte behalten ihre
typisierten Envelopes für Zustände wie `partial`, `failed` und `in_doubt`.
Diese Zustände müssen dauerhaft untersuchbar bleiben und werden nicht als
flüchtige HTTP-Ausnahme versteckt. Der Frontendadapter normalisiert während der
Kompatibilitätsphase zusätzlich ältere `message`-/`error`-Payloads.

Ein OpenAPI-Schema-Transformer beschreibt diese Erweiterungen im
eingecheckten 3.1-Vertrag. Der generierte TypeScript-Client speist `AppProblem`
und `toAppProblem`; Views raten die Transportstruktur nicht selbst.

`AsyncStatePanel` stellt Loading, Empty, Error, Offline, Stale und Partial
semantisch dar, zeigt nur technische Trace-/Operation-Metadaten und bietet die
passende Recovery-Aktion. Sichere GETs dürfen begrenzt wiederholt werden;
Mutationen werden nie automatisch wiederholt. Sichtbare Daten bleiben bei
Background-Refresh oder einem Fehler einer sekundären Detailabfrage erhalten.

Migriert wurden:

- Dashboard und Task Strip;
- Agents, Agent Detail, Agent Create und Proposal Detail;
- Projects, Project Detail, Task Board und Task Detail;
- Run Control und Run Detail;
- Calendar, Memory, Docs und Incidents;
- Models, Activity, Notifications, Security und Settings.

Memory, Docs und Incidents verlieren ihre bereits sichtbare Liste nicht mehr,
wenn nur eine Detail- oder Suchabfrage fehlschlägt. Agent Detail blockiert die
Primäransicht nicht länger wegen einer fehlerhaften Sekundärabfrage.

### CI und Supply Chain

- Ein separater verpflichtender Linux-Job führt alle als
  `DockerIntegration` oder `ToxiproxyIntegration` markierten Tests mit beiden
  Opt-ins aus. Fehlendes Docker ist ein Jobfehler, kein Skip.
- Frontend und Backend blockieren High/Critical-Produktionsabhängigkeiten.
- Gitleaks `8.30.1` wird als Upstream-Artefakt geladen, über einen gepinnten
  SHA-256 geprüft und gegen die vollständige Git-Historie ausgeführt.
- Drei überprüfte historische Fingerprints sind exakt baselined; die aktuelle
  Arbeitskopie ist redigiert. Eine eventuelle Credential-Rotation oder
  History-Rewrite bleibt ein gesonderter, ausdrücklich freizugebender
  Sicherheitsvorgang.
- Das Fixture-Playwright-Profil deaktiviert Browsertelemetrie. Das
  Produktionsimage aktiviert nur den allow-listeten bestehenden
  Browsermetrikpfad über `VITE_BROWSER_TELEMETRY_ENABLED=true`.

## Lokale Abnahme

| Gate | Ergebnis |
|---|---|
| Frontend Typecheck | grün |
| Frontend Unit Tests | 13 Dateien, 42 Tests bestanden |
| Frontend Production Build | grün |
| Playwright | 26/26 bestanden |
| Geschützte Routen | alle 20 in kontrollierten Fixtures geprüft |
| Viewports | 375, 768, 1024, 1440 und 1920 px ohne Seitenoverflow |
| Browserverträge | Deep Links, Query-Deduplizierung, ein SSE-Resync, Task-Board-Refresh, Done-Pagination, Drag-and-drop und 503-Recovery grün |
| Backend | 386 bestanden; fünf Containerfälle mangels lokalem Docker explizit übersprungen |
| PostgreSQL-Ausfall | echter Npgsql-Healthcheck gegen einen nicht erreichbaren Endpoint liefert im Readiness-Vertrag 503 |
| Version | `VERSION` und Frontendpaket beide `0.2.60`; .NET-Pin wird als 10.0.101 aus dem erlaubten Feature-Band aufgelöst |
| Abhängigkeiten | keine bekannten pnpm-Produktionslücken; keine High/Critical-NuGet-Funde |
| Compose/Workflows | Compose valide, Deploy-Shell syntaktisch valide, CI- und Rollback-YAML parsebar |
| OpenAPI | neu generiert; entfernte CSRF-Route, neue Readiness-Route und Problemfelder enthalten |

Playwright arbeitet mit kontrollierten API-Fixtures. Diese Ergebnisse beweisen
die UI- und Transportverträge, nicht die echte Produktionsdatenqualität oder
OpenClaw-/OpenAI-Ausführung.

## CI- und Produktionsevidenz

Die verpflichtenden Gates haben vor der Freigabe mehrere reale Fehler gefunden:

- Run 363 blockierte einen fehlerhaft geordneten EF-Core-Modellsnapshot für
  `AgentProposal.ProvisionRequests`.
- Anschließende Läufe zeigten, dass drei historische Taskmigrationen ohne
  EF-Metadaten nicht entdeckt wurden. Alle 13 Migrationen sind jetzt
  registriert; der Snapshot weist keinen ausstehenden Modellunterschied auf.
- Der Toxiproxy-Reconcile-Fall deckte zuerst einen leeren serialisierten
  `agents.create`-Payload und danach fehlendes Read-back-Inventar im Testadapter
  auf. Beide Grenzen besitzen Regressionstests.
- Der OpenAPI-Build erzeugte anfangs einen flüchtigen Data-Protection-Key. Die
  Extraktion arbeitet jetzt ohne persistente Schlüssel; CI prüft den
  Key-Repository-Dateizähler vor und nach beiden .NET-Builds.

Der finale Gitea Run 372 deployte Commit
`f87b9ef298f8a13ed7e044f9850024aa50fbbed0` mit folgender Evidenz:

| Gate | Produktionsergebnis |
|---|---|
| Backend, Job 818 | 386 Tests bestanden |
| PostgreSQL/Toxiproxy, Job 819 | 5/5 bestanden, null übersprungen |
| Frontend, Job 820 | 13 Dateien/42 Tests, Build und 26/26 Playwright bestanden |
| Security, Job 821 | gepinntes Gitleaks 8.30.1 ohne Leak; Dependency-Gates grün |
| Deployment, Job 822 | alle Container gesund; lokale und öffentliche Readiness sowie vollständige Diagnose grün |

Der öffentliche Smoke-Test bestätigte anschließend:

- `/health/live` und `/health/ready`: HTTP 200 `Healthy`;
- `/health`: HTTP 200 mit PostgreSQL `Healthy` und OpenClaw-HTTP-Runtime
  `Online`;
- `/login`: HTTP 200, CSP, HSTS, `DENY`, `no-referrer` und eingeschränkte
  Browserberechtigungen;
- geschützte OpenClaw-API: HTTP 401 als `application/problem+json` mit
  `unauthenticated` und Trace-ID;
- Cross-Site-Refresh und -Logout: HTTP 403 als strukturierter `forbidden`-
  Fehler.

Im In-App-Browser blieb die Loginseite ohne Console-Fehler bedienbar. Es wurden
keine Zugangsdaten eingegeben oder ausgelesen.

## Offene Abnahmegates

### Mit separater Owner-Sitzung

- Alle 20 authentifizierten Produktionsviews werden read-only auf Navigation,
  Requests, Konsole, Refresh/Reload/Logout, echte Agent-/Cron-/Modell-/Security-
  Daten, SSE-Freshness, Tastatur und Overflow geprüft.
- Kein OpenClaw-Schreibtest wird dabei ausgeführt.

### Noch nicht Teil dieses Release-Slices

- Task Board mit 1.000 Tasks und 10.000 Activities: k6-p95,
  SQL-Statementzählung, `EXPLAIN (ANALYZE, BUFFERS)` und wiederholte
  Navigation-bis-Karten-sichtbar-Messung.
- Produktive Protocol-v4-Verbindung und Management. OpenClaw `2026.7.1`
  registriert weiterhin keine offiziell unterstützte externe Nexus-/Generic-
  Operator-ID. Die neuen offiziellen Seiten zu
  [Gateway clients](https://docs.openclaw.ai/gateway/clients) und
  [external apps](https://docs.openclaw.ai/gateway/external-apps) ändern den
  geschlossenen Connect-Schema-/Client-ID-Vertrag noch nicht.
- Ein echter `Nexus -> OpenClaw -> OpenAI -> Nexus`-Run, Wegwerf-Cron oder
  Testagent. Diese Mutationen benötigen nach erfülltem Identity-Gate eine
  separate Owner-Freigabe.

## Nächste Reihenfolge

1. Bao meldet sich im In-App-Browser als Owner an; danach 20 Seiten read-only
   auditieren und jeden Fund mit Route, API, Trace-ID und Regressionstest
   erfassen.
2. Den Refresh-Vertrag über einen kontrollierten API-Containerneustart mit
   echter Owner-Sitzung belegen.
3. Task-Board-Datensatz und Last-/SQL-/Browserbudgets isoliert beweisen; nur
   gemessene Engpässe optimieren.
4. OpenClaw-Client-ID auf dem ersten kompatiblen Stable-Tag erneut prüfen und
   erst dann read-only pairen.
5. Danach Run Explorer, Agent Lifecycle, Notifications/Incidents, Calendar,
   Knowledge und Security in der bestehenden Roadmap-Reihenfolge schließen.
