# Abnahmebericht – Vendoo Production Updater 3.4 **Status:** in technischer Abnahme **Branch:** `feature/updater-3.4-lifecycle` **Pull Request:** `#28` **Zielversion:** Vendoo `1.43.0` **Updater-Version:** `3.4.0` ## Verbindliche Ausgangslage - `main` basiert auf dem gültigen Release aus PR #26. - PR #27 ist geschlossen, nicht gemergt und kein zulässiger Quellstand. - Der alte Worker 3.3 ist aus dem aktiven Release-Payload entfernt. - Persistente Produktionsdaten unter `/app/data` sind nicht Bestandteil des Payloads. - PR #28 bleibt bis zum vollständigen Linux-/Windows-Nachweis ein Draft. ## Ist-/Lückenanalyse Updater 3.3 | Bereich | Reale 3.3-Lücke | Umsetzung 3.4 | Nachweis | |---|---|---|---| | Check-Registrierung | `gh pr checks --watch` konnte bei noch nicht registrierten Checks sofort mit `no checks reported` abbrechen | eigener Check-Classifier mit 90 Sekunden Grace Period | Regressionstest und GitHub-CI ausstehend | | Manifest-Sync | Head-SHA konnte sich nach Start der Checkphase ändern | aktuelle `headRefOid` wird in jeder Runde gelesen; Wechsel startet Grace Period und Auswertung neu | Regressionstest und Integrationstest ausstehend | | Wiederholung nach Merge | 3.3 suchte nur offene PRs und konnte nach einem Merge erneut Sourcearbeit beginnen | gemergter passender PR führt direkt in Deployment/Verifikation | Regressionstest vorhanden, CI ausstehend | | `main` bereits Zielversion | 3.3 erzeugte weiterhin Arbeitskopie und Releasebranch | Sourcephase wird vollständig übersprungen | Regressionstest vorhanden, CI ausstehend | | Produktion bereits Zielversion | kein sofortiger erfolgreicher Zielzustand | sofortiger Erfolg ohne Branch, PR oder Deployment | Regressionstest vorhanden, reale Produktionsprobe ausstehend | | veralteter Payload | Overlay plus Force-Push konnte neuere `main`-Änderungen zurücksetzen | Provenienz v2, Base-Ancestor-Prüfung und Pfadkonflikt-Guard vor dem Overlay | realer temporärer Git-Regressionstest vorhanden, CI ausstehend | | Branch/PR-Idempotenz | Branch wurde stets neu erzeugt und unbedingt mit `--force` gepusht | deterministischer Branch, PR-Reconciliation und `--force-with-lease` | statischer Vertrag vorhanden, Windows-Lauf ausstehend | | Check-Lifecycle | keine konkrete Workflow-Run-Auswertung am finalen Head | Rollup plus Actions-Runs nach `head_sha`, neuester Run entscheidet | Regressionstests vorhanden, GitHub-Lauf ausstehend | | Merge-Sicherheit | kein atomarer Nachweis, dass der gemergte Head geprüft wurde | `--match-head-commit` mit unmittelbar zuvor bestätigtem finalen SHA | statischer Vertrag vorhanden, Integration ausstehend | ## Zustandsautomat Der verbindliche Automat ist in `docs/PRODUCTION_UPDATER_3_4.md` dokumentiert. Die terminalen Zustände sind: - `COMPLETED`: GitHub- und Produktionsziel nachgewiesen, - `FAILED`: terminaler Pflichtcheck, Payloadkonflikt, Timeout oder technischer Fehler, - `CANCELLED`: expliziter Benutzerabbruch mit erhaltenem Sitzungsstand. Ein fehlender oder noch laufender Check ist kein terminaler Fehler. ## Regressionstest-Matrix | Szenario | Erwartung | Automatisierter Test | Linux | Windows | |---|---|---:|---:|---:| | verspätet registrierte Checks | innerhalb Grace Period weiter warten | vorhanden | ausstehend | ausstehend | | `queued` / `pending` / `in_progress` | nicht fehlschlagen | vorhanden | ausstehend | ausstehend | | Manifest-Sync erzeugt neuen Head | alten Head verwerfen, neuen Head vollständig prüfen | Worker-/Lifecycle-Vertrag vorhanden | ausstehend | ausstehend | | bereits gemergter PR | keinen zweiten PR erzeugen | vorhanden | ausstehend | ausstehend | | bereits deployte Zielversion | sofort erfolgreich ohne Änderungen | vorhanden | ausstehend | ausstehend | | doppelter Start | vorhandenen Zustand übernehmen | Entscheidungs- und Sessionvertrag vorhanden | ausstehend | ausstehend | | parallele Workflow-Runs | zeitlich neuesten Run bewerten | vorhanden | ausstehend | ausstehend | | veralteter Payload gegen neueren `main` | vor Overlay blockieren | realer temporärer Git-Test vorhanden | ausstehend | ausstehend | | blockierter Rückschritt | Konfliktpfade ausgeben, keine Sourceänderung | vorhanden | ausstehend | ausstehend | | älterer Erfolg, neuerer Fehler | neuer Fehler ist terminal | vorhanden | ausstehend | ausstehend | | älterer Fehler, neuer Lauf | neuer Lauf bleibt pending | vorhanden | ausstehend | ausstehend | | älterer Abbruch, neuer Erfolg | neuer Erfolg gilt | vorhanden | ausstehend | ausstehend | ## Releasevertrag Vor einer Freigabe müssen nachweislich erfolgreich sein: 1. Syntax- und Sicherheitsgates unter Linux, 2. vollständiges `npm run verify:all` unter Windows, 3. PowerShell-Parserprüfung von UI, Host und Worker34, 4. Manifest-Reproduzierbarkeit, 5. Release-Staging mit `vendoo-release-package-v2`, 6. SHA-256-Prüfung aller Paketdateien, 7. Nachweis, dass der alte Worker 3.3 nicht ausgeliefert wird, 8. keine Änderung an Datenbank- oder `/app/data`-Inhalten, 9. Review des finalen PR-Head-SHA. ## Noch offene Abnahmepunkte - GitHub-CI für den finalen PR-Head muss vollständig grün sein. - Der Windows-Vertrag muss den echten PowerShell-Parser und alle bestehenden Tests erfolgreich durchlaufen. - Das auslieferbare Paket darf erst danach erzeugt und als Workflow-Artefakt übernommen werden. - Die öffentliche Produktionsantwort konnte in dieser Arbeitsumgebung noch nicht unabhängig verifiziert werden; sie ist daher kein bereits erbrachter Nachweis. ## Freigabeentscheidung **Noch nicht freigegeben.** Es existiert noch kein als produktionsreif deklarierter Download. Der Bericht wird erst nach finaler CI-, Paket- und Produktionsabnahme auf „bestanden“ gesetzt.