# Vendoo Production Updater 3.2

## Architekturwechsel

Updater 3.2 verwendet keine Ausschlusslisten-Kopie und leert die geklonte `main`-Arbeitskopie nicht mehr.

Der Release enthält `release-manifest.json` mit:

- jeder auszuliefernden Quelldatei,
- Dateigröße,
- SHA-256-Prüfsumme,
- verbindlichen Pflichtdateien,
- ausschließlich expliziten Löschungen in `removedFiles`.

## Anwendung

1. `main` wird in einen isolierten Arbeitsordner geklont.
2. Das gesamte Paket wird gegen `release-manifest.json` geprüft.
3. Sichere Paketdateien, die nicht im Manifest stehen, blockieren das Update.
4. Manipulierte oder fehlende Dateien blockieren das Update.
5. Der Release wird als Overlay angewendet; bestehende Baseline-Dateien bleiben erhalten.
6. Nur Einträge in `removedFiles` werden gelöscht.
7. Jede kopierte Datei wird im Ziel erneut per SHA-256 geprüft.
8. Erst danach laufen `npm ci` und `npm run verify:all`.

## Pflichtdateien

Unter anderem müssen immer vorhanden sein:

- `db/schema.sql`
- `lib/db.mjs`
- `package.json`
- `package-lock.json`
- `server.mjs`
- `bootstrap.mjs`
- Updater-Preflight, UI, Host und Worker

## Sitzungen

Sitzungsstände der Updater-2.x-Reihe werden nicht übernommen. Updater 3.2 beginnt mit einem neuen Release-Branch und einer neuen, versionsgebundenen Sitzung.

## Steuerdatei-Vertrag 3.2

`release-manifest.json` ist kein selbstgehashter Payload-Eintrag. Der Applier kopiert es nach erfolgreicher Payload-Prüfung als separates Steuerartefakt bytegenau in die Git-Arbeitskopie. Verifier in einer Git-Baseline dürfen zusätzliche unveränderte Dateien sehen, müssen aber jede manifestierte Datei und ihre SHA-256-Prüfsumme bestätigen.

## Fehlerdarstellung

Bei fehlgeschlagenen Prozessen priorisiert der Worker `stderr` als **Fehlerausgabe** und zeigt `stdout` nur gekürzt als ergänzende **letzte Standardausgabe**. Dadurch bleibt die eigentliche Ursache im Statusfenster sichtbar.