docs: record v0.2.60 production acceptance [skip ci]

2026-08-01 02:24:37 +02:00
parent f87b9ef298
commit a83de81031
5 changed files with 105 additions and 65 deletions
@@ -39,18 +39,21 @@ isolated from the frontend and the Nexus domain model.
 > **Structured operation results checkpoint (2026-07-31):**
 > [implementation and acceptance](docs/audits/2026-07-31/operation-results-deep-links/IMPLEMENTATION_AND_ACCEPTANCE.md).
 >
-> **Production release v0.2.59 (2026-07-31):**
+> **Previous production checkpoint v0.2.59 (2026-07-31):**
 > [production validation, route matrix and next plan](docs/audits/2026-07-31/production-release-v0.2.59/PRODUCTION_VALIDATION_AND_NEXT_PLAN.md).
 > Gitea run 362 deployed commit `144edf58fe5928a3e04816f4435ea574d64211a1`;
 > PostgreSQL and the OpenClaw HTTP runtime are healthy. Productive Protocol-v4
 > management remains intentionally blocked by the external Client-ID gate.
 >
-> **Stability and recovery v0.2.60 candidate (2026-07-31):**
+> **Production release v0.2.60 — stability and recovery (2026-07-31):**
 > [implementation and acceptance](docs/audits/2026-07-31/stability-v0.2.60/IMPLEMENTATION_AND_ACCEPTANCE.md).
 > Readiness, browser-origin protection, generated ProblemDetails metadata,
 > shared UI recovery states, version provenance and mandatory container-backed
-> CI are implemented. The audit separates locally proven behavior from the
+> CI are deployed from commit `f87b9ef298f8a13ed7e044f9850024aa50fbbed0`
-> Linux/Docker, deployment, credentialed-production and OpenClaw-write gates.
+> through Gitea run 372. All 386 regular backend tests, all five PostgreSQL/
 > Toxiproxy tests, 42 frontend tests, 26 Playwright tests and the pinned
 > full-history Gitleaks scan passed. Credentialed production, Task Board load
 > evidence and productive OpenClaw writes remain separate acceptance gates.
 > 📋 **Architektur-Review** (2026-06-22): Board-first Orchestrierung, sichere
 > Backend-Brücke und Gateway-Integration geprüft. Siehe
@@ -1,6 +1,6 @@
 # Nexus Agent-First Mission Control
-**Status:** Zielvertrag mit produktivem v0.2.59-Control-Plane-Stand und implementiertem v0.2.60-Stabilitätskandidaten; Linux-/Docker-Releasegate, Gateway-Writes, credentialed Live-Abnahme und Lastnachweis offen
+**Status:** Zielvertrag mit produktiv deploytem v0.2.60-Stabilitätsfundament; Gateway-Writes, credentialed Live-Abnahme und Lastnachweis offen
 **Stand:** 2026-07-31
 **Geltungsbereich:** Produkt, Frontend, Backend, Runtime-Adapter und Agenten-Schnittstellen
@@ -129,7 +129,7 @@ Produktionscheckpoint v0.2.59 vom 2026-07-31:
 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:
+Produktionscheckpoint v0.2.60 vom 2026-07-31:
 - `/health/live`, `/health/ready` und `/health` trennen Prozesszustand,
  PostgreSQL-Readiness und vollständige OpenClaw-Diagnose. Deploy und Rollback
@@ -145,11 +145,16 @@ Stabilitätscheckpoint v0.2.60 (Release Candidate) vom 2026-07-31:
 - `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 384 nicht-containerisierte Backendtests, 42 Frontendtests,
+- Gitea Run 372 hat Commit
-  Typecheck, Produktionsbuild und 26 kontrollierte Playwright-Tests. Die fünf
+  `f87b9ef298f8a13ed7e044f9850024aa50fbbed0` nach 386 regulären Backendtests,
-  Containerfälle sind lokal mangels Docker übersprungen und müssen im Linux-CI
+  fünf bestandenen PostgreSQL-/Toxiproxy-Tests ohne Skip, 42 Frontendtests,
-  mit null Skips bestehen. Credentialed Produktion, Task-Board-Last und echte
+  Typecheck, Produktionsbuild, 26 Playwright-Tests sowie Dependency- und
-  OpenClaw-Schreibpfade bleiben eigene Gates.
+  Gitleaks-Gates deployt. Der OpenAPI-Build hinterließ keinen persistierten
  Data-Protection-Key.
 - Die Container und öffentlichen Health-Gates sind gesund; Login,
  Security-Header, strukturierte 401/403-Antworten und die Cross-Site-Sperre
  für Refresh/Logout sind live geprüft. 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).
@@ -475,11 +480,12 @@ regressionsfest.
 - 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
+**Checkpoint 2026-07-31:** Das produktive v0.2.60-Stabilitätsfundament enthält
 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
+Breiten ab. Gitea Run 372 hat die Linux-/Docker-, Security-, Frontend- und
 Deployment-Gates vollständig bestanden. Offen bleiben die credentialed
 Produktionsprüfung, der 1.000/10.000-Task-Board-Lastnachweis sowie reale
 OpenClaw-/OpenAI-End-to-End-Evidenz.
@@ -584,29 +590,28 @@ nicht die M1-/M2-Vertrauensgrenze umgehen.
 ## 9. Nächster empfohlener Implementierungsslice
-**Slice: „Official external identity and controlled live acceptance“**
+**Slice: „Credentialed read-only production acceptance“**
-1. Upstream eine offiziell unterstützte externe `nexus`- oder generische
+1. Bao stellt im In-App-Browser eine Owner-Sitzung bereit; Zugangsdaten werden
-   Operator-Client-ID verwenden und Nexus auf die erste unterstützende
+   weder ausgelesen noch dokumentiert.
-   OpenClaw-Version pinnen; keine reservierte interne Identität imitieren.
+2. Alle 20 authentifizierten Produktionsviews werden ohne Mutation auf
-2. Auf Baos ausdrücklich freigegebener OpenClaw-Instanz read-only verbinden,
+   Navigation, Deep Links, Requests, Konsole, reale Daten, SSE-Freshness,
-   die konkrete Pairing-Request-ID freigeben lassen und Agent-/Cron-Inventar
+   Tastaturführung und Overflow geprüft.
-   gegen den erwarteten Bestand abgleichen, ohne Runtime-Daten zu kopieren.
+3. Reload, Token-Refresh, Logout und erneute Anmeldung werden einschließlich
-3. Den bewussten Admin-Scope-Upgrade separat pairen und Endpoint-, Device-,
+   Rückkehrziel und genau einer Redirectentscheidung belegt. Der noch offene
-   TLS-, Scope- und Capability-Bindung im Security Center belegen.
+   Refresh-Nachweis über einen kontrollierten API-Containerneustart wird in
-4. Ausschließlich an eindeutig benannten Testobjekten je einen
+   diesem Slice abgeschlossen.
-   Hashkonflikt-/Read-back-Test für Agent-Datei und Config sowie Create/Edit/
+4. Jeder Fund erhält Route, API, Reproduktion, Trace-ID, Schweregrad und einen
-   Run/History/Delete für Cron durchführen. Andere Ressourcen bleiben
+   Regressionstest. P0/P1 blockieren den nächsten Release-Slice.
-   unangetastet.
+5. Dashboard und Iris bleiben dabei read-only; es findet kein produktiver
-5. OpenAI ausschließlich in OpenClaw als Primärprovider für Iris konfigurieren
+   OpenClaw-Schreibtest statt.
   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
+Direkt danach folgt der isolierte Task-Board-Performance-Slice mit 1.000 Tasks,
-vollständigen Beweis, dass Attach & Adopt sowie ein normaler agent-first
+10.000 Activities, k6, SQL-Zähler, Queryplan und Browsermessung. Das externe
-Arbeitsablauf ohne Wechsel in die OpenClaw-Oberfläche sicher funktionieren.
+OpenClaw-Identity-Gate läuft parallel weiter: Erst eine offiziell unterstützte
 `nexus`- oder generische Operator-Client-ID erlaubt Pairing, Scope-Upgrade und
 die separat freizugebenden Live-Schreibtests. Reservierte interne Identitäten
 werden nicht imitiert.
 ## 10. Definition of Done für „kein OpenClaw-Wechsel mehr“
@@ -35,6 +35,16 @@ The repository SDK contract is `global.json`: .NET `10.0.100` with
 `latestFeature` roll-forward. `VERSION` is the release source of truth;
 frontend package version and OCI image labels are checked against it.
 Accepted release evidence from 2026-07-31 is Gitea run 372 at commit
 `f87b9ef298f8a13ed7e044f9850024aa50fbbed0`: 386 regular backend tests, all
 five PostgreSQL/Toxiproxy tests with zero skips, 42 frontend unit tests, 26
 Playwright tests, the dependency gates and the pinned full-history Gitleaks
 scan passed before deployment. OpenAPI extraction also proved that neither
 .NET build added a persistent Data Protection key. This is release evidence
 for the fixture and container contracts; it is not a substitute for the still
 pending credentialed production audit, Task Board load run, or live OpenClaw
 write acceptance.
 ## Browser route and recovery gate
 The fixture Playwright profile sets `VITE_BROWSER_TELEMETRY_ENABLED=false`, so
@@ -2,8 +2,8 @@
 **Stand:** 2026-07-31
-**Status:** Release Candidate; lokale Verträge grün, Linux-/Docker-CI und
+**Status:** In Produktion deployt; technische Releasegates grün, credentialed
-Produktionsdeployment noch auszuführen
+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
@@ -11,16 +11,17 @@ Prüfbereichs.
 ## Ergebnis
-Der erste Stabilitäts- und Fehlerabbau-Slice ist implementiert. Nexus trennt
+Der erste Stabilitäts- und Fehlerabbau-Slice ist implementiert und deployt.
-jetzt Prozess-Liveness, Datenbank-Readiness und vollständige Runtime-Diagnose,
+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 Produktions- oder OpenClaw-Abnahme. Der
+Das ist noch keine vollständige authentifizierte Produktions- oder
-credentialed Owner-Audit, Task-Board-Lastnachweis und jeder produktive
+OpenClaw-Abnahme. Der Owner-Audit, Task-Board-Lastnachweis und jeder produktive
 OpenClaw-Schreibvorgang bleiben getrennte Gates.
 ## Implementierter Vertrag
@@ -124,7 +125,7 @@ Primäransicht nicht länger wegen einer fehlerhaften Sekundärabfrage.
 | 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 | 384 bestanden; fünf Containerfälle mangels lokalem Docker explizit übersprungen |
+| 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 |
@@ -135,30 +136,50 @@ 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
 Der erste verpflichtende Containerlauf (Gitea Run 363) erfüllte seinen Zweck
 und blockierte das Deployment: Alle fünf Fälle fanden einen fehlerhaft
 geordneten EF-Core-Modellsnapshot für
 `AgentProposal.ProvisionRequests`. Die Snapshotbeziehung ist korrigiert und ein
 nicht-Docker-Regressionstest baut beide Navigationen jetzt bereits im normalen
 Backendjob auf. Ein neuer grüner Containerlauf bleibt vor Deployment zwingend.
 ### Vor Deployment
 1. Der neue Gitea-Linuxjob muss alle fünf vorhandenen PostgreSQL-/Toxiproxy-
   Containerfälle bestehen, null überspringen und Docker als erreichbar melden.
 2. Der Gitleaks-Vollhistorienjob, OpenAPI-Diff, Dependency-Gates und die übrigen
   Backend-/Frontendjobs müssen grün sein.
 3. Das versionierte Image muss mit SHA-Provenienz gebaut und durch dieselben
   Readiness-/Diagnosegates deployt werden.
 ### Nach Deployment, ohne Owner-Sitzung
 - `/health/live`, `/health/ready`, `/health`, `/login`, Security-Header und ein
  unauthentifizierter geschützter API-Aufruf werden öffentlich geprüft.
 - Die Produktion muss `v0.2.60` und den ausgelieferten Git-SHA melden.
 ### Mit separater Owner-Sitzung
 - Alle 20 authentifizierten Produktionsviews werden read-only auf Navigation,
@@ -183,10 +204,11 @@ Backendjob auf. Ein neuer grüner Containerlauf bleibt vor Deployment zwingend.
 ## Nächste Reihenfolge
-1. Linux-/Docker-CI und Deployment-Smoke für v0.2.60 abschließen.
+1. Bao meldet sich im In-App-Browser als Owner an; danach 20 Seiten read-only
 2. 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