AzuTear
218 lines
11 KiB
Markdown
218 lines
11 KiB
Markdown
# 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.
|