docs/PRODUCTION_UPDATER_3_4.md

@@ -125,7 +125,7 @@ Für jeden aktuellen PR-Head werden ausgewertet:
 
 - `statusCheckRollup` des Pull Requests,
 - Workflow-Runs aus `actions/runs?head_sha=<finaler-head>&per_page=100`,
-- die Pflichtchecks `Syntax, Sicherheit und Release-Gates` sowie `Windows – vollständiger Releasevertrag`,
+- die Pflichtchecks `Syntax, Sicherheit und Release-Gates`, `Windows – vollständiger Releasevertrag` und `Updater-3.4-Paket nach Abnahme`,
 - die Pflichtworkflows `Vendoo CI` und `Vendoo Release Manifest Sync`.
 
 Regeln:
@@ -137,6 +137,19 @@ Regeln:
 - Vor dem Merge wird der Head-SHA erneut gelesen.
 - Der Merge verwendet `--match-head-commit`; ein weiterer Headwechsel verhindert den Merge atomar.
 
+### Final-Head-Registrierung nach Manifest-Sync
+
+Ein Push mit dem GitHub-Workflow-Token startet für den dadurch erzeugten Commit nicht automatisch einen weiteren Push-Workflow. Deshalb bestätigt der Manifest-Sync nach seinem Commit zuerst den tatsächlichen Remote-Head und dispatcht anschließend explizit:
+
+1. `Vendoo CI` für den neuen Head,
+2. `Vendoo Release Manifest Sync` für denselben Head.
+
+Der zweite Manifest-Sync-Lauf findet ein unverändertes Manifest, erzeugt keinen weiteren Commit und dient als konkreter erfolgreicher Workflow-Nachweis am finalen SHA. Die Concurrency des Sync-Workflows darf den auslösenden Lauf nicht abbrechen.
+
+### Paket erst nach Plattformabnahme
+
+Das auslieferbare ZIP entsteht im Job `Updater-3.4-Paket nach Abnahme`. Dieser Job besitzt eine harte `needs`-Abhängigkeit auf Linux- und Windows-Abnahme. Er läuft daher erst, wenn beide Verträge erfolgreich abgeschlossen wurden. Danach werden Root-Manifest, Paketmanifest v2, Zielversion, Updater-Version und ZIP-SHA-256 erneut geprüft. Nur dieses Artefakt ist ein auslieferbarer Kandidat.
+
 ## Sitzungsvertrag
 
 Sitzungen verwenden `vendoo-updater-session-v2`. Die Identität besteht aus: