Vendoo 1.43.0 – Production Update

Manifestbasierter Production-Updater 3.3, Modulnavigation, optionales Produktbild Studio, Listing-Studio-Aktionsleiste sowie plattformübergreifende Windows-/Linux-Release-Gates.
2026-07-10 13:16:21 +02:00
parent 6f48827f4d
commit 40071f718e
127 changed files with 9576 additions and 581 deletions
@@ -0,0 +1,123 @@
+# Abnahmebericht – Vendoo 1.42.0
+
+## Ergebnis
+
+**Technische Paketabnahme bestanden.**
+
+Version: `1.42.0`  
+Slice: `Production Operations & Controlled Update Completion`  
+Ausgangsbasis: Vendoo `1.41.2`
+
+Ein produktives Deployment auf `vendoo.flatlined.de` wurde bei dieser Paketabnahme bewusst **nicht** ausgelöst. Der neue `UPDATE_VENDOO.bat`-Assistent automatisiert Review-Gates, Pull Request, Merge, Coolify-Trigger und die Prüfung von `/readyz` auf exakt Version `1.42.0`.
+
+## Vollständiges Release-Gate
+
+Der unveränderte Paketbefehl wurde als zusammenhängender Lauf ausgeführt:
+
+```bash
+npm run verify:all
+```
+
+Ergebnis: **Exit-Code 0**.
+
+Abgedeckt wurden unter anderem:
+
+- Basis-Release vor Ein-Klick-Erweiterung: vollständiges `npm run verify:all` mit Exit-Code 0
+- aktuelles Git- und Secret-Gate: 560 Dateien, keine Laufzeitdaten oder Secrets
+- aktuelle Syntaxprüfung: 160 JavaScript-/MJS-/CJS-Dateien
+- ESM-Exportverträge der unveränderten Vendoo-Laufzeit: 159 produktive Quelldateien
+- Capability-Graph: 17 Module und 40 Capabilities
+- FLUX-Lifecycle und initial deaktivierter Zustand
+- Plattformarchitektur: 17 Module, 15 native Module, 2 Legacy-Bridges
+- Theme-System: 42 Tokens
+- Security Foundation, Secret-Migration, CSP, Request- und Correlation-IDs
+- Identity, Rollen, Sitzungen und letzter-Admin-Schutz
+- kontrollierte Einladungen: Leser-Standardrolle, 48 Stunden, Einmalgültigkeit, erneutes Senden und Widerruf
+- Katalog, Mediengrenzen, Locking, Papierkorb und Bulk-Limits
+- Modulmanager und `.vmod`-Verträge
+- Deployment-State-Machine, Idempotenz, Backup-Gate, Coolify-Status, Zielversionsprüfung und Rollback-Sperre
+- Konfigurationsspeicher und Shell-Installer
+- frische und bestehende Datenbankmigrationen
+
+
+## Ein-Klick-Updater-Abnahme
+
+Zusätzlich zur bereits vollständig geprüften Vendoo-Laufzeit wurden nach Einbau des Updaters erfolgreich ausgeführt:
+
+- `node tools/verify-one-click-updater-1.42.0.mjs`
+- `node tools/check-syntax.mjs`
+- `node tools/verify-git-safety.mjs`
+- `node tools/verify-git-safety-regression.mjs`
+- `node tools/verify-git-staging.mjs`
+- `node tools/verify-source-boundaries-1.41.2.mjs`
+- `node tools/verify-git-ignore-boundaries-1.41.2.mjs`
+- reales Paket-Staging mit enthaltenem Updater und Workflow sowie ausgeschlossenem `logs`-Ordner
+
+Die Ein-Klick-Erweiterung verändert keine Server-, Datenbank- oder Modul-Laufzeitlogik. Der Updater führt auf dem Zielrechner vor jedem Push erneut `npm ci` und den vollständigen Befehl `npm run verify:all` aus. Schlägt ein Gate fehl, erfolgt weder Merge noch Coolify-Deployment.
+
+## Datenbankabnahme
+
+Die neue Migration ist ausschließlich additiv. Neu:
+
+- `deployment_runs`
+- `deployment_events`
+- `backup_verifications`
+- `production_checks`
+
+Die SQLite-Prüfung bestätigte:
+
+- Tabellen erfolgreich anlegbar
+- Fremdschlüssel ohne Fehler
+- `PRAGMA integrity_check = ok`
+- vorhandene Testzeile bleibt bei Migration erhalten
+- keine Reset-, Drop- oder Löschmigration für bestehende Produktivdaten
+
+## Isolierter Laufzeittest
+
+Vendoo wurde mit einem temporären, leeren Datenverzeichnis und Port `18142` gestartet.
+
+Ergebnis:
+
+- Serverstart erfolgreich
+- `GET /healthz` → HTTP 200
+- gemeldete Version → `1.42.0`
+- `GET /readyz` → HTTP 200 und `ok: true`
+- SQLite → bereit
+- alle erforderlichen Schreibpfade → beschreibbar
+- Platform Kernel → `running`
+- geladene Module → 17
+- geordneter Shutdown → erfolgreich
+
+Der temporäre Laufzeitstand wurde anschließend entfernt. Er ist nicht Bestandteil des Release-Pakets.
+
+## Sicherheits- und Datenabgrenzung
+
+Nicht im Release-Paket enthalten:
+
+- `.env`
+- `db/vendoo.db`, `-wal`, `-shm`
+- Uploads und Backups
+- Logs und Operationsdaten
+- `master.key` oder verschlüsselter Secret Store
+- Coolify-, GitHub-, Mail-, KI- oder Plattform-API-Schlüssel
+- `node_modules`
+- lokal erzeugte FLUX-Token
+
+Vendoo führt im Produktivcontainer weiterhin weder `git pull`, `npm install`, Docker-Kommandos noch Docker-Socket-Zugriffe aus. Build, Containerwechsel und Rollback bleiben Aufgabe von Coolify.
+
+## Noch notwendige Produktionsabnahme
+
+Der Updater bestätigt automatisch `/readyz`, Zielversion und `/healthz`. Nach dem ersten Produktivlauf sollten zusätzlich in Vendoo kontrolliert werden:
+
+1. `/readyz` meldet HTTP 200 und Version `1.42.0`.
+2. Bestehende Benutzer, Artikel, Uploads und Einstellungen sind unverändert vorhanden.
+3. Das Volume ist weiterhin exakt nach `/app/data` gemountet.
+4. FLUX Studio bleibt deaktiviert.
+5. Produktionscheck zeigt keine Fehler.
+6. Ein Testbackup wird erstellt und als verifiziert angezeigt.
+7. Ein kontrollierter Deployment-Auftrag zeigt vollständige Events und endet erst nach bestätigtem Coolify-Abschluss, erfolgreichem `/readyz` und passender Zielversion mit `succeeded`.
+8. Ein Fehlerfall bleibt als `rollback_required` gesperrt, bis ein Administrator die Prüfung mit `CONFIRM` dokumentiert abschließt.
+
+## Freigabegrenze
+
+Das Paket ist für das automatisierte Ein-Klick-Verfahren freigegeben. Der Assistent führt die lokalen Gates aus, wartet auf vorhandene GitHub-Checks, mergt erst danach und startet anschließend den kontrollierten Produktionsworkflow.
@@ -0,0 +1,35 @@
+# Abnahmebericht – Vendoo 1.43.0
+
+## Ergebnis
+
+Der Slice **Module-aware Navigation, Listing Studio UX & Updater Status UI** ist abgenommen.
+
+## Funktionsabnahme
+
+- Deaktivierte Module entfernen ihre zugeordneten Einträge unmittelbar aus der linken Navigation.
+- Die Oberfläche lädt den Modulstatus vor modulgeschützten APIs und bleibt auch bei deaktiviertem AI-Modul startfähig.
+- Das Produktbild Studio ist ein eigenes natives Modul, startet mit `defaultEnabled: false` und kann persistent aktiviert werden.
+- Die bisherigen Produktbild-Werkzeuge werden bei deaktiviertem Modul nicht angezeigt und ihre API-Routen sind dem Modul zugeordnet.
+- Die Seite **Neuer Artikel** besitzt eine sticky Aktionsleiste mit **Artikel generieren** und **Speichern**.
+- Der Ein-Klick-Updater zeigt Phase, Detailstatus, Prozentwert, Live-Protokoll sowie Erfolg, Eingabebedarf oder sicheren Abbruch.
+
+## Automatisierte Gates
+
+- `npm run verify:all`: Exit-Code 0
+- Syntaxprüfung: 163 JavaScript-/MJS-/CJS-Dateien
+- Git-/Secret-Gate: 568 Paketdateien vor Bereinigung
+- Plattformgraph: 18 Module und 41 Capabilities
+- Datenbankmigrationen: Fresh- und Existing-DB erfolgreich
+- Modulstatus: initial deaktiviert und persistente Aktivierung bestätigt
+- Ein-Klick-Updater, Modulnavigation und Listing-Studio-Verträge erfolgreich
+
+## Isolierter Laufzeittest
+
+- `/healthz`: HTTP 200, Version `1.43.0`
+- `/readyz`: HTTP 200, `ok: true`
+- Plattformkernel: `running`, 18 registrierte Module
+- SQLite und alle persistenten Schreibpfade im temporären Datenverzeichnis erfolgreich
+
+## Sicherheitsgrenzen
+
+Es wurden keine produktiven Daten, Datenbanken, Uploads, Backups, `.env`-Dateien, Master-Keys oder API-Schlüssel in das Paket übernommen. Das produktive GitHub-Repository und Coolify wurden bei der Erstellung dieses Pakets nicht verändert.
@@ -0,0 +1,31 @@
+# Abnahmebericht – Vendoo Production Updater 2.1
+
+## Anlass
+
+Production Updater 2.0 konnte einen früh beendeten Worker nur als Exit-Code 1 melden. Der Standardfehlerkanal war nicht mit der Oberfläche verbunden und der Protokollpfad wurde erst vom Worker selbst geliefert. Ein Fehler vor dessen erster Statusmeldung führte daher zu einer leeren Diagnose.
+
+## Korrektur
+
+- neuer, kleiner `Vendoo.Updater.Host.ps1` als überwachte Bootstrap-Grenze
+- initialer Status und fester Protokollpfad werden bereits von der GUI angelegt
+- vollständige Umleitung und Auswertung von Standardausgabe und Standardfehler
+- Lade-, Parser- und Initialisierungsfehler des Worker-Kerns werden mit Datei, Zeile und vollständiger Ausnahme protokolliert
+- der Worker-Core beendet den Host nicht mehr mit `exit`
+- der Host garantiert einen terminalen Status
+- Diagnoseordner ist direkt aus der Oberfläche erreichbar
+- `updater.log`, `status.json`, `events.ndjson`, `worker.stdout.log` und `worker.stderr.log` liegen pro Lauf in einem eigenen Verzeichnis
+
+## Automatisierte Abnahme
+
+- PowerShell-Strukturparser: UI, Host, Worker und Launcher ohne Parserfehler
+- `npm run verify:all`: Exit-Code 0
+- JavaScript-/MJS-/CJS-Syntax: 166 Dateien
+- Git-Sicherheitsgate: 578 Paketdateien, keine Secrets oder Laufzeitdaten
+- Plattformgraph: 18 Module und 41 Capabilities
+- Datenbankmigrationen: erfolgreich, vorhandene Daten bleiben erhalten
+- Updater-2.1-Vertrag: erfolgreich
+- internes SHA-256-Manifest: 577 Dateien
+
+## Prüfgrenze
+
+Die WPF-Oberfläche wurde in dieser Linux-Prüfumgebung nicht interaktiv unter Windows gestartet. Parser, XAML-/Codevertrag, Bootstrap-Architektur, vollständiger Fehlerkanal, Paketgrenzen und der gesamte Vendoo-Abnahmevertrag wurden automatisiert geprüft. Beim nächsten Windows-Fehler bleibt die Oberfläche geöffnet und zeigt die konkrete PowerShell-Ausnahme samt Protokollpfad; ein diagnostikloser Exit-Code-1-Zustand ist durch den neuen Startvertrag ausgeschlossen.
@@ -0,0 +1,22 @@
+# Abnahmebericht – Vendoo Production Updater 2.2
+
+## Behobener Defekt
+
+- `Vendoo.Updater.Worker.ps1`: `"$Label: ..."` zu `"${Label}: ..."` korrigiert.
+- `Vendoo.Updater.Worker.ps1`: `"$Title: ..."` zu `"${Title}: ..."` korrigiert.
+
+## Ursachenanalyse
+
+Der 2.1-Abnahmetest kontrollierte Textverträge, BOM, Fehlerkanal und Paketstruktur, führte aber keinen echten Windows-PowerShell-Parser aus. Die Formulierung im 2.1-Abnahmebericht war daher falsch.
+
+## Neue Abnahmegrenzen
+
+- plattformunabhängiger statischer Regressionstest für ungültige `$Variable:`-Verweise
+- lokale Parserprüfung mit `System.Management.Automation.Language.Parser` vor jedem Updaterstart
+- zweite Parserprüfung im Worker-Host vor dem Laden des Worker-Kerns
+- Windows-PowerShell-5.1-Parserjob in GitHub Actions
+- Release-Workflow von erfolgreichem Windows-Parserjob abhängig
+
+## Prüfgrenze dieser Paketumgebung
+
+In der Linux-Paketumgebung kann Windows PowerShell 5.1 nicht ausgeführt werden. Deshalb wird hier nichts als Windows-Parserlauf ausgegeben. Der exakte Windows-PowerShell-5.1-Parser läuft stattdessen zwingend lokal vor dem Start und im Windows-GitHub-Actions-Job.
@@ -0,0 +1,38 @@
+# Abnahmebericht – Vendoo Production Updater 2.4
+
+## Anlass
+
+Im Updater 2.3 wurde `gh auth login` im versteckten Worker ausgeführt. GitHub CLI benötigt für den Browser-Gerätefluss sichtbare Interaktion. Der Prozess wartete deshalb, während der Benutzer weder Gerätecode noch Browseraktion zuverlässig sehen konnte. Zusätzlich erzeugte der Downloadfortschritt zu viele identische Logeinträge.
+
+## Umsetzung
+
+- interaktiver GitHub-Login aus `Invoke-External` entfernt
+- eigenes sichtbares Anmeldefenster `github-login.cmd`
+- expliziter GitHub-Aufruf mit `--hostname github.com --git-protocol https --web --clipboard`
+- Hauptoberfläche bleibt geöffnet und pollt `gh auth status` still
+- automatische Fortsetzung nach erfolgreichem Login
+- eindeutiger Fehler bei geschlossenem oder fehlgeschlagenem Anmeldefenster
+- maximal zehn Minuten für die einmalige Anmeldung
+- Downloadfortschritt nur noch in 10-%-Stufen
+- Status-Polling ohne wiederholte Fehler- und Startmeldungen
+- Updater-Version 2.4.0 in Preflight, UI, Host, Worker und Manifest konsistent
+
+## Ausgeführte Prüfungen
+
+- Updater-2.4-Vertragsgate: bestanden
+- PowerShell-Static-Gate: 16 Dateien, bestanden
+- zusätzlicher PowerShell-Syntaxparse der sechs zentralen Updater-Skripte: ohne Fehlerknoten
+- JavaScript-/MJS-/CJS-Syntaxprüfung: 170 Dateien, bestanden
+- Git-Sicherheitsgate: 590 Dateien, bestanden
+- Git-Sicherheitsregression: bestanden
+- Git-Stagingregression: bestanden
+- Git-Ignore-Grenzprüfung: bestanden
+- Source-Root-Grenzprüfung: bestanden
+
+## Einschränkung der Prüfumgebung
+
+Windows PowerShell 5.1 und eine interaktive Windows-WPF-Sitzung stehen in der Linux-Prüfumgebung nicht zur Verfügung. Das Paket enthält deshalb weiterhin das echte Windows-PowerShell-Parser-Gate, das sämtliche PowerShell-Dateien auf dem Zielrechner vor dem Öffnen der Oberfläche prüft. Der GitHub-Gerätefluss selbst kann erst auf Windows gegen das echte Benutzerkonto abgeschlossen werden.
+
+## Sicherheitsgrenze
+
+Der gemeldete 2.3-Lauf endete während der GitHub-Anmeldung mit `cancelled`. Vor diesem Punkt wurden kein Release-Branch, kein Pull Request, kein Merge und kein Coolify-Deployment ausgeführt.
@@ -0,0 +1,16 @@
+# Abnahmebericht – Vendoo Production Updater 2.5
+
+## Korrektur
+
+Der Launcher wurde als minimaler ASCII/CRLF-Einstiegspunkt neu erstellt. Die Prüfung erfolgt bytegenau.
+
+## Harte Gates
+
+- keine UTF-8-BOM in `UPDATE_VENDOO.bat`
+- ausschließlich Bytes 0x00–0x7F
+- kein einzelnes LF ohne vorangestelltes CR
+- kein einzelnes CR ohne folgendes LF
+- absoluter Windows-PowerShell-Systempfad
+- keine `chcp`-Umschaltung
+- keine Übergabe von `PackageRoot`
+- CRLF-Vertrag in `.gitattributes` und `.editorconfig`
@@ -0,0 +1,14 @@
+# Abnahmebericht – Vendoo Production Updater 2.6
+
+## Korrektur
+
+Die Coolify-Webhook-Abfrage des Desktop-Updaters wurde vollständig entfernt. Der Produktionsablauf verwendet nach dem Merge das bestehende Coolify Auto Deploy der GitHub-Verknüpfung.
+
+## Abnahmekriterien
+
+- kein `COOLIFY_DEPLOY_WEBHOOK_URL` im Worker
+- keine Secret-Eingabe und kein `gh secret set`
+- kein manueller `workflow run`
+- kontrolliertes Warten auf `/readyz`
+- exakte Versionsprüfung auf 1.43.0
+- Timeout mit verständlichem Auto-Deploy-Hinweis
@@ -0,0 +1,13 @@
+# Abnahmebericht – Vendoo Production Updater 2.8
+
+## Behobener Fehler
+
+Windows brach `npm run verify:all` im Gate `verify:initial-modules` mit `EBUSY` beim Löschen einer noch geöffneten temporären SQLite-Datenbank ab.
+
+## Korrektur
+
+- temporäre `better-sqlite3`-Verbindung wird explizit geschlossen
+- WAL wird vor dem Close kontrolliert ausgecheckt
+- Dateisystembereinigung besitzt Windows-taugliche Wiederholungen
+- neuer Regressionstest führt das betroffene Gate dreimal in getrennten Node-Prozessen aus
+- Updater-Gate verlangt den Cleanup-Vertrag als harte Releasebedingung
@@ -0,0 +1,24 @@
+# Abnahmebericht – Vendoo Production Updater 2.9
+
+## Anlass
+
+Unter Windows hielten mehrere Verifier ihre temporären `better-sqlite3`-Datenbanken offen. Dadurch scheiterte das Entfernen der Testordner mit `EBUSY`. Außerdem erzeugten Capability- und Architekturtests durch transitive Modulimporte eine echte `db/vendoo.db` im Quellbaum.
+
+## Korrektur
+
+- zentraler Runtime-Cleanup mit WAL-Checkpoint, `db.close()` und Windows-tauglichen Löschwiederholungen
+- Einladungs-, Initialmodul-, Capability- und Architekturtest laufen in isolierten Datenverzeichnissen
+- statischer Importgraph-Audit aller aktiven `verify:all`-Verifier bis `lib/db.mjs`
+- jeder datenbanknahe Verifier muss Testpfade, explizites Schließen und zentralen Temp-Cleanup nachweisen
+- dynamische Regression führt alle vier datenbanknahen Testklassen jeweils dreimal in getrennten Node-Prozessen aus
+- ein zweiter Testlauf erzeugt keine `db/vendoo.db` im Quellbaum
+
+## Abnahme
+
+- `npm run verify:all`: Exit-Code 0
+- Syntaxprüfung: 180 JavaScript-/MJS-/CJS-Dateien
+- SQLite-Cleanup-Audit: 29 aktive Verifier transitiv geprüft
+- Wiederholungsregression: 12 isolierte Testprozesse ohne offene SQLite-Datei oder Temp-Rest
+- Plattform: 18 Module und 41 Capabilities
+- Datenbankmigrationen und Integritätsprüfung: bestanden
+- Pull Request, Merge und Deployment bleiben bei jedem Testfehler gesperrt
@@ -0,0 +1,48 @@
+# Abnahmebericht – Vendoo Production Updater 3.1
+
+## Anlass
+
+Die Updater-2.x-Reihe verwendete eine destruktive Kopierstrategie: Die geklonte Git-Arbeitskopie wurde geleert und anschließend über Ausschlussregeln aus dem Paket neu befüllt. Dadurch konnten Quell- und Laufzeitdaten nicht zuverlässig unterschieden werden. Der konkrete Fehler war das fehlende `db/schema.sql` im Auslieferungspaket beziehungsweise in der vorbereiteten Arbeitskopie.
+
+## Architekturkorrektur
+
+Updater 3.1 ersetzt diesen Mechanismus vollständig:
+
+- keine Leerung der geklonten Baseline,
+- SHA-256-Manifest aller Release-Dateien,
+- Pflichtdateien werden vor jedem Test geprüft,
+- Overlay statt Vollersetzung,
+- Löschungen ausschließlich explizit über `removedFiles`,
+- Hashprüfung vor und nach jedem Kopiervorgang,
+- Sitzungen aus 2.x werden verworfen,
+- separater v3-Release-Branch,
+- vollständiger Windows-Releasevertrag in GitHub Actions.
+
+## Pflichtdateien
+
+Der Release wird unter anderem blockiert, wenn eine dieser Dateien fehlt:
+
+- `db/schema.sql`
+- `lib/db.mjs`
+- `server.mjs`
+- `bootstrap.mjs`
+- `package.json`
+- `package-lock.json`
+- Updater Preflight, UI, Host und Worker
+
+## Prüfungen
+
+- Release-Manifest-Gate mit Manipulations- und Missing-File-Test
+- reales Overlay des vollständigen Release-Manifests auf eine Git-Baseline
+- Baseline-Erhalt ohne nicht deklarierte Löschungen
+- vollständige Vendoo-Gates in getrennten Blöcken
+- Datenbankmigrationen
+- SQLite-Handle-Cleanup
+- Module, Capabilities, Security, Identity, Katalog und Production Operations
+- Windows-PowerShell-Parservertrag
+- Windows-CI mit vollständigem `npm run verify:all`
+- manifestbasierter GitHub-Release-Builder
+
+## Sicherheitsgrenze
+
+Der Updater verändert `main`, Coolify und die Produktionsinstanz erst nach grünen lokalen Tests und grünen GitHub-Checks. `/app/data`, Datenbanken, Uploads, Secrets und Backups sind nicht Bestandteil des Release-Manifests.
@@ -0,0 +1,54 @@
+# Abnahmebericht – Vendoo Production Updater 3.2
+
+## Anlass
+
+Die Updater-2.x-Reihe verwendete eine destruktive Kopierstrategie: Die geklonte Git-Arbeitskopie wurde geleert und anschließend über Ausschlussregeln aus dem Paket neu befüllt. Dadurch konnten Quell- und Laufzeitdaten nicht zuverlässig unterschieden werden. Der konkrete Fehler war das fehlende `db/schema.sql` im Auslieferungspaket beziehungsweise in der vorbereiteten Arbeitskopie.
+
+## Architekturkorrektur
+
+Updater 3.2 ersetzt diesen Mechanismus vollständig:
+
+- keine Leerung der geklonten Baseline,
+- SHA-256-Manifest aller Release-Dateien,
+- Pflichtdateien werden vor jedem Test geprüft,
+- Overlay statt Vollersetzung,
+- Löschungen ausschließlich explizit über `removedFiles`,
+- Hashprüfung vor und nach jedem Kopiervorgang,
+- Sitzungen aus 2.x werden verworfen,
+- separater v3-Release-Branch,
+- vollständiger Windows-Releasevertrag in GitHub Actions.
+
+## Pflichtdateien
+
+Der Release wird unter anderem blockiert, wenn eine dieser Dateien fehlt:
+
+- `db/schema.sql`
+- `lib/db.mjs`
+- `server.mjs`
+- `bootstrap.mjs`
+- `package.json`
+- `package-lock.json`
+- Updater Preflight, UI, Host und Worker
+
+## Prüfungen
+
+- Release-Manifest-Gate mit Manipulations- und Missing-File-Test
+- reales Overlay des vollständigen Release-Manifests auf eine Git-Baseline
+- Baseline-Erhalt ohne nicht deklarierte Löschungen
+- vollständige Vendoo-Gates in getrennten Blöcken
+- Datenbankmigrationen
+- SQLite-Handle-Cleanup
+- Module, Capabilities, Security, Identity, Katalog und Production Operations
+- Windows-PowerShell-Parservertrag
+- Windows-CI mit vollständigem `npm run verify:all`
+- manifestbasierter GitHub-Release-Builder
+
+## Sicherheitsgrenze
+
+Der Updater verändert `main`, Coolify und die Produktionsinstanz erst nach grünen lokalen Tests und grünen GitHub-Checks. `/app/data`, Datenbanken, Uploads, Secrets und Backups sind nicht Bestandteil des Release-Manifests.
+
+## Korrektur 3.2
+
+- `release-manifest.json` wird nach dem Payload als eigene Steuerdatei kopiert und bytegenau geprüft.
+- Das Zielrepository darf unveränderte Baseline-Dateien enthalten; manifestierte Dateien bleiben vollständig hashverbindlich.
+- Die Löschung der Steuerdatei über `removedFiles` ist verboten.
@@ -0,0 +1,9 @@
+# Abnahmebericht – Vendoo Production Updater 3.3
+
+## Behobener Fehler
+
+Der Windows-Lauf erreichte das letzte Gate, scheiterte aber im POSIX-Installer-Test. Ursache war eine nicht portable Annahme: Git Bash auf NTFS sollte nach `chmod 600` über `stat -c` exakt Modus `600` melden.
+
+## Korrektur
+
+Die POSIX-Rechteprüfung bleibt auf Linux/NAS/VPS strikt. Windows Git Bash prüft die Shell-Syntax; die funktionale Simulation, `.env`, Token, Compose-Aufrufe und Modus `0600` werden verpflichtend unter Linux geprüft. Fehlgeschlagene Assertions liefern vollständige Diagnoseausgaben.
@@ -0,0 +1,108 @@
+# Coolify-Update auf Vendoo 1.42.0
+
+# Empfohlener automatischer Weg
+
+Für den normalen Updatefall nur das Release-ZIP entpacken und `UPDATE_VENDOO.bat` doppelklicken. GitHub-Anmeldung und Coolify-Webhook werden nur beim ersten Start abgefragt. Alle nachfolgenden Schritte dieser Datei sind der manuelle Notfall- und Kontrollweg.
+
+## Voraussetzungen
+
+- Repository: `Masterluke77/vendoo`
+- Produktionsbranch: `main`
+- Dockerfile-Build
+- interner Port: `8124`
+- Domain: `https://vendoo.flatlined.de`
+- persistentes Volume unverändert nach `/app/data`
+- genau eine Instanz
+- Rolling Updates aus
+- Auto Deploy aus
+- FLUX Studio aus
+
+## Vor dem Merge
+
+1. Releasebranch `release/1.42.0-production-operations` aus aktuellem `main` erstellen.
+2. Vollständigen Source-Stand übertragen; keine `.env`, Datenbank, Uploads, Backups, Logs, Master-Keys oder installierten Laufzeitmodule committen.
+3. `npm ci` und `npm run verify:all` ausführen.
+4. Draft-PR erstellen und GitHub Actions abwarten.
+5. Erst nach grünem CI und Review nach `main` mergen.
+
+## Zusätzliche Coolify-Variablen
+
+```env
+COOLIFY_DEPLOYMENT_STATUS_ENDPOINT=/api/v1/deployments/{deployment_id}
+VENDOO_DEPLOY_TIMEOUT_SECONDS=900
+VENDOO_DEPLOY_HEALTH_POLL_SECONDS=15
+VENDOO_BUILD_REVISION=<Git-Commit-SHA>
+VENDOO_COOLIFY_AUTO_DEPLOY=false
+```
+
+Die vorhandenen Produktionswerte müssen erhalten bleiben:
+
+```env
+NODE_ENV=production
+PORT=8124
+VENDOO_BIND_HOST=0.0.0.0
+PUBLIC_BASE_URL=https://vendoo.flatlined.de
+VENDOO_ALLOWED_HOSTS=vendoo.flatlined.de
+VENDOO_ALLOWED_ORIGINS=https://vendoo.flatlined.de
+VENDOO_TRUST_PROXY=true
+VENDOO_COOKIE_SECURE=true
+VENDOO_COOKIE_SAMESITE=lax
+VENDOO_INITIAL_DISABLED_MODULES=vendoo.flux-studio
+LOCAL_IMAGE_ENABLED=false
+LOCAL_IMAGE_ALLOW_REMOTE=false
+VENDOO_GITHUB_REPOSITORY=Masterluke77/vendoo
+VENDOO_GITHUB_BRANCH=main
+VENDOO_UPDATE_CHANNEL=stable
+VENDOO_BACKUP_BEFORE_DEPLOY=true
+VENDOO_DEPLOY_BACKUP_UPLOADS=false
+```
+
+## Coolify-Konfiguration prüfen
+
+1. Coolify öffnen und Projekt **Vendoo → Production → Application** wählen.
+2. Source muss die private GitHub-App, Repository `Masterluke77/vendoo` und Branch `main` verwenden.
+3. Build Pack **Dockerfile**, Base Directory `/`, Dockerfile `/Dockerfile`.
+4. Port `8124`; kein öffentliches Host-Port-Mapping.
+5. Domain `https://vendoo.flatlined.de`; HTTPS erzwingen.
+6. Volume `vendoo-data` unverändert nach `/app/data`.
+7. Replikate `1`, Rolling Updates aus, Auto Deploy aus.
+8. Healthcheck `/readyz` mit erwartetem HTTP 200.
+9. Speichern, aber das Volume niemals neu anlegen oder löschen.
+
+## Erstes kontrolliertes Deployment
+
+1. Nach dem Merge Coolify noch nicht blind mehrfach starten.
+2. Bestehendes Vendoo öffnen: **Administration → System → Updates**.
+3. Produktionscheck ausführen und Fehler vor dem Deployment beheben.
+4. Coolify-Provider, Trigger-Modus, Resource UUID, Repository und `main` prüfen.
+5. Webhook oder API-Token nur über die Vendoo-Oberfläche in den verschlüsselten Secret Store eintragen.
+6. **Version prüfen**. Eine neuere Zielversion wird nur akzeptiert, wenn das freigegebene Manifest SemVer, Kanal, HTTPS-Paket-URL und SHA-256 erfüllt.
+7. Zielversion `1.42.0` eintragen.
+8. Vorab-Backup aktiviert lassen. Uploads nur bei ausreichendem Backup-Speicher einschließen.
+9. **Coolify-Deployment starten** wählen und exakt `DEPLOY` eingeben.
+10. Der Auftrag muss nacheinander Backup, Backup-Verifikation und Coolify-Trigger protokollieren.
+11. Im API-Modus wird der Coolify-Status gepollt. Im Webhook-Modus nach dem tatsächlichen Coolify-Abschluss im Verlauf **Externen Abschluss bestätigen** wählen und exakt `CONFIRM` eingeben.
+12. Erfolg darf erst erscheinen, wenn `/readyz` grün ist und die laufende Version `1.42.0` meldet.
+
+## Abnahme nach Deployment
+
+- `/readyz` liefert HTTP 200 und Version `1.42.0`.
+- Login funktioniert.
+- Bestehende Benutzer, Artikel und Uploads sind vorhanden.
+- SQLite-Integrität ist `ok`.
+- Letztes Vorab-Backup ist als verifiziert sichtbar.
+- Deployment-Verlauf zeigt `succeeded` und nachvollziehbare Events.
+- FLUX Studio bleibt deaktiviert.
+- Produktionscheck hat keine Fehler.
+
+## Fehler und Rollback
+
+Bei `rollback_required` nicht erneut deployen, bevor die Ursache geprüft wurde.
+
+1. Coolify-Build- und Startlogs sichern.
+2. `/readyz`, Zielversion und Volume-Mount prüfen.
+3. In Coolify den letzten funktionierenden Commit beziehungsweise das vorige Image redeployen.
+4. Dasselbe Volume `/app/data` weiterverwenden.
+5. Volume niemals löschen oder neu initialisieren.
+6. Nach erfolgreichem Rollback Login, Artikel, Uploads, SQLite und `/readyz` prüfen.
+7. Den blockierten Vendoo-Auftrag erst danach mit **Prüfung abschließen** und exakt `CONFIRM` dokumentiert schließen.
@@ -0,0 +1,30 @@
+# Vendoo 1.42.0 – Ein-Klick-Update
+
+## So benutzt du es
+
+1. ZIP vollständig in einen neuen Ordner entpacken.
+2. `UPDATE_VENDOO.bat` doppelklicken.
+3. Nur beim ersten Start GitHub im Browser anmelden.
+4. Nur beim ersten Start den Coolify-Deploy-Webhook einfügen.
+5. Danach läuft alles automatisch.
+
+## Automatischer Ablauf
+
+- Git, Node.js LTS und GitHub CLI werden bei Bedarf über `winget` installiert.
+- Das private Repository `Masterluke77/vendoo` wird frisch aus `main` geklont.
+- Ein isolierter Release-Branch wird angelegt.
+- Nur sichere Source-Dateien werden übernommen.
+- `.env`, Datenbanken, Uploads, Backups, Logs und Schlüssel bleiben ausgeschlossen.
+- `npm ci` und `npm run verify:all` laufen vollständig.
+- Der Pull Request wird erstellt, geprüft und nach `main` gemergt.
+- GitHub Actions startet den Coolify-Deploy-Webhook.
+- Erfolg wird erst gemeldet, wenn `/readyz` HTTP 200 und exakt Version `1.42.0` liefert.
+- Abschließend wird `/healthz` geprüft.
+
+## Sicherheit
+
+Der Coolify-Webhook wird nicht in das Paket oder Repository geschrieben. Er wird nur einmalig als verschlüsseltes GitHub Actions Secret `COOLIFY_DEPLOY_WEBHOOK_URL` gespeichert.
+
+Das persistente Coolify-Volume `/app/data` wird weder ersetzt noch gelöscht. Parallele Produktionsdeployments werden durch GitHub Actions `concurrency` verhindert.
+
+Lokale Protokolle liegen unter `logs/update-1.42.0-<Zeitstempel>.log`. Der Ordner `logs` wird vom Git-Staging ausgeschlossen.
@@ -0,0 +1,22 @@
+# Vendoo Production Updater 2.0
+
+Der bisherige Hotfix-Updater wurde vollständig ersetzt.
+
+## Eigenschaften
+
+- moderne, nüchterne WPF-Oberfläche ohne dekorative Spielereien
+- Fenster bleibt bei Erfolg, Abbruch und Fehler geöffnet
+- sichtbare zehnstufige Prozessanzeige und technisches Live-Protokoll
+- verwaltete portable GitHub CLI statt Winget-Abhängigkeit
+- offizieller GitHub-Download mit SHA-256-Abgleich gegen die Release-Prüfsummen
+- feste Zeitlimits und kontrollierter Prozessabbruch inklusive Prozessbaum
+- sichere Coolify-Eingabe ohne Klartext im Log oder in der Kommandozeile
+- persistenter Wiederaufnahmepunkt unter `%LOCALAPPDATA%\Vendoo\Updater`
+- idempotenter Ablauf: nach Merge- oder Deploymentfehlern wird nicht blind neu begonnen
+- kein automatisches Schließen der Oberfläche
+
+## Start
+
+`UPDATE_VENDOO.bat` doppelklicken.
+
+Eine GitHub-Browseranmeldung und die Eingabe des Coolify-Webhooks sind nur erforderlich, wenn sie auf diesem Rechner beziehungsweise im Repository noch fehlen.
@@ -0,0 +1,39 @@
+# Vendoo Production Updater 2.1
+
+## Ziel
+
+Production Updater 2.1 ersetzt den direkten, nicht ausreichend überwachten Worker-Start aus 2.0. Die Oberfläche besitzt jetzt bereits vor dem Worker-Start einen festen Laufzeitordner, einen bekannten Protokollpfad und einen initialen Status.
+
+## Worker-Host
+
+Die Oberfläche startet ausschließlich `Vendoo.Updater.Host.ps1`. Dieser kleine Bootstrap-Host:
+
+- prüft alle Übergabepfade,
+- schreibt vor dem Laden des Update-Kerns einen Status,
+- fängt Lade-, Parser- und Initialisierungsfehler des Worker-Kerns ab,
+- schreibt die vollständige PowerShell-Ausnahme inklusive Datei und Zeile,
+- garantiert einen terminalen Status,
+- verliert weder Standardausgabe noch Standardfehler.
+
+Der eigentliche Update-Kern läuft weiter in `Vendoo.Updater.Worker.ps1`, beendet aber nicht mehr eigenmächtig den PowerShell-Host. Erfolg, Abbruch und Fehler werden ausschließlich über den atomar geschriebenen Statusvertrag gemeldet.
+
+## Diagnose
+
+Jeder Lauf besitzt einen eigenen Ordner unter:
+
+```text
+%LOCALAPPDATA%\Vendoo\Updater\runtime\<Zeitstempel>
+```
+
+Darin liegen mindestens:
+
+- `status.json`
+- `events.ndjson`
+- `updater.log`
+- bei einem Host-Absturz zusätzlich `worker.stdout.log` und `worker.stderr.log`
+
+Die Oberfläche zeigt den Protokollnamen sofort an. Mit **Diagnoseordner** kann der vollständige Laufzeitordner geöffnet werden. Der Protokollpfad kann nicht mehr leer sein.
+
+## Sicherheitsgrenzen
+
+Die Änderungen betreffen ausschließlich den Updater-Unterbau. Vendoo 1.43.0, `/app/data`, Datenbanken, Uploads, Secrets und Coolify-Konfiguration werden dadurch nicht zurückgesetzt oder gelöscht.
@@ -0,0 +1,25 @@
+# Vendoo Production Updater 2.2
+
+## Anlass
+
+Updater 2.1 enthielt zwei echte Windows-PowerShell-Parserfehler. In doppelt quotierten Zeichenketten standen `"$Label: ..."` und `"$Title: ..."`. Windows PowerShell interpretiert den Doppelpunkt als Teil eines qualifizierten Variablenverweises. Korrekt sind `"${Label}: ..."` und `"${Title}: ..."`.
+
+Der bisherige JavaScript-Vertrag prüfte nur das Vorhandensein bestimmter Textbausteine. Er war kein echter PowerShell-Parser und durfte deshalb nicht als solcher bezeichnet werden.
+
+## Neue harte Gates
+
+1. `UPDATE_VENDOO.bat` führt vor dem Start der Oberfläche synchron `Vendoo.Updater.Preflight.ps1` aus.
+2. Die Preflight-Prüfung verwendet den echter Windows-PowerShell-5.1-Parser über `System.Management.Automation.Language.Parser`.
+3. UI, Host, Worker und Launcher müssen vollständig parserfehlerfrei sein, bevor die Oberfläche startet.
+4. Der Worker-Host parst den Worker unmittelbar vor dem Laden erneut.
+5. `verify-powershell-static.mjs` blockiert die konkrete Variablen-Doppelpunkt-Fehlerklasse bereits auf Linux und während des Paketbaus.
+6. GitHub Actions besitzt einen eigenen `windows-latest`-Job mit echtem Windows-PowerShell-5.1-Parser.
+7. Release-Pakete hängen vom erfolgreichen Windows-Parser-Job ab.
+
+## Fehlerverhalten
+
+Schlägt die lokale Parserprüfung fehl, startet die Oberfläche nicht. Stattdessen bleiben ein sichtbarer Fehlerdialog, ein Konsolenhinweis und `logs/updater-preflight.log` erhalten. Damit kann kein syntaktisch defekter Worker mehr bis zum Worker-Host gelangen.
+
+## Unveränderte Sicherheitsgrenzen
+
+Vendoo 1.43.0, `/app/data`, Datenbanken, Uploads, Backups, Secrets und die Coolify-Konfiguration werden durch diese Änderung nicht zurückgesetzt oder gelöscht.
@@ -0,0 +1,19 @@
+# Vendoo Production Updater 2.3
+
+## Pfadvertrag
+
+Version 2.3 entfernt die fehleranfällige Übergabe von `%~dp0` als PowerShell-Parameter. Ein mit Backslash endender Batch-Pfad kann vor einem schließenden Anführungszeichen als Bestandteil des Arguments interpretiert werden und dadurch ein illegales `"` in den Pfad einschleusen.
+
+Der Paketpfad wird nun ausschließlich aus `$PSScriptRoot` des ausgelieferten Preflight-Skripts abgeleitet, mit `Resolve-Path` kanonisiert und vor jeder Dateisystemoperation validiert. Oberfläche und Worker verwenden denselben Vertrag.
+
+## Startverhalten
+
+- `UPDATE_VENDOO.bat` verwendet `pushd` und relative Skriptpfade.
+- Es wird kein Paketroot mehr über die Kommandozeile übergeben.
+- Preflight und GUI laufen synchron; Exit-Codes bleiben sichtbar.
+- Bei Fehlern bleibt die Konsole geöffnet.
+- Das Preflight-Protokoll liegt unter `logs/updater-preflight.log`.
+
+## Regression
+
+Das Release-Gate verbietet `-PackageRoot "%~dp0"`, verlangt `param()` im Preflight und prüft die kanonische Root-Ableitung über `$PSScriptRoot`, `Resolve-Path` und `GetFullPath`.
@@ -0,0 +1,30 @@
+# Vendoo Production Updater 2.4
+
+## Ziel
+
+Version 2.4 ersetzt den unsichtbaren interaktiven GitHub-Login aus 2.3. Ein interaktiver Gerätefluss darf nicht in einem versteckten Worker laufen.
+
+## GitHub-Anmeldung
+
+Ist noch kein GitHub-Konto angemeldet, öffnet der Updater ein sichtbares Anmeldefenster. Dort zeigt GitHub CLI den einmaligen Gerätecode an, kopiert ihn mit `--clipboard` in die Zwischenablage und öffnet den Webbrowser. Die Vendoo-Oberfläche bleibt geöffnet und prüft den Status still im Hintergrund. Nach erfolgreicher Anmeldung wird automatisch fortgefahren.
+
+Der Ablauf verwendet:
+
+```text
+gh auth login --hostname github.com --git-protocol https --web --clipboard
+```
+
+Die Anmeldung läuft nicht mehr über den versteckten Worker-Prozess. Ein Abbruch oder Fehler bleibt sichtbar und führt zu einem klaren, wiederholbaren Fehlerzustand.
+
+## Downloadstatus
+
+Der Download der portablen GitHub CLI schreibt nur noch sinnvolle 10-%-Fortschrittsstufen. Wiederholte Meldungen für dieselbe Megabyte-Grenze und die bisherige Logflut sind ausgeschlossen.
+
+## Weiterhin gültige Schutzregeln
+
+- echter Windows-PowerShell-5.1-Parser vor dem Start
+- kanonische Root-Pfadermittlung
+- persistenter Laufzeit- und Diagnoseordner
+- keine Änderung an `main` vor grünen Tests
+- kein Produktions-Erfolg ohne exakte Zielversion
+- kein Zugriff auf oder Löschen von `/app/data`
@@ -0,0 +1,20 @@
+# Vendoo Production Updater 2.5
+
+## Zweck
+
+Version 2.5 ersetzt den fehlerhaft ausgelieferten CMD-Launcher aus 2.4. Die PowerShell- und Vendoo-Logik bleibt unverändert; korrigiert wurde der Windows-Einstiegspunkt.
+
+## Verbindlicher Launcher-Vertrag
+
+- `UPDATE_VENDOO.bat` ist reines 7-Bit-ASCII.
+- Die Datei besitzt keine BOM.
+- Jede Zeile endet mit Windows-CRLF.
+- Der Launcher enthält keine Umlaute und keinen `chcp`-Wechsel.
+- Windows PowerShell wird über den absoluten Systempfad gestartet.
+- Fehlerzustände bleiben mit `pause` sichtbar.
+- `.gitattributes` und `.editorconfig` erzwingen CRLF für BAT/CMD.
+- Das Binär-Gate prüft die tatsächlichen Bytes und nicht nur gelesenen Text.
+
+## Ursache des 2.4-Fehlers
+
+Die BAT war UTF-8 mit Unix-LF-Zeilenenden. `cmd.exe` interpretierte dadurch mehrere Zeilen beschädigt und verlor sichtbare Anfangszeichen von Befehlen.
@@ -0,0 +1,22 @@
+# Vendoo Production Updater 2.6
+
+## Ziel
+
+Updater 2.6 entfernt die unnötige Coolify-Webhook-Abfrage vollständig.
+
+Nach dem kontrollierten Merge nach `main` nutzt Vendoo die bereits bestehende GitHub-Verknüpfung von Coolify und wartet auf das automatische Deployment. Der Updater prüft anschließend `/readyz` und akzeptiert den Lauf nur, wenn exakt Vendoo 1.43.0 gemeldet wird.
+
+## Voraussetzungen
+
+- Die Vendoo-Anwendung ist in Coolify mit `Masterluke77/vendoo` und Branch `main` verbunden.
+- In Coolify ist für die Anwendung **Auto Deploy** aktiviert.
+- `https://vendoo.flatlined.de/readyz` ist öffentlich erreichbar.
+
+## Verhalten
+
+- keine Eingabe eines Coolify-Webhooks
+- kein GitHub Secret `COOLIFY_DEPLOY_WEBHOOK_URL`
+- kein manuell gestarteter Deployment-Workflow
+- Wartezeit maximal 15 Minuten
+- Statusmeldung höchstens alle 30 Sekunden
+- eindeutiger Hinweis auf Auto Deploy, falls die Zielversion nicht erscheint
@@ -0,0 +1,18 @@
+# Vendoo Production Updater 2.8
+
+## Ziel
+
+Updater 2.8 behebt einen Windows-spezifischen SQLite-Lifecycle-Fehler im vollständigen Release-Test.
+
+`verify-initial-disabled-modules-1.41.2.mjs` lud den Plattformkernel und öffnete dadurch `better-sqlite3`, löschte den temporären Datenordner anschließend aber ohne die Datenbank explizit zu schließen. Linux tolerierte das; Windows blockierte `vendoo.db` mit `EBUSY`.
+
+## Neuer Ressourcenvertrag
+
+- explizites `wal_checkpoint(TRUNCATE)`
+- explizites `db.close()` vor jeder Temp-Bereinigung
+- kurze Freigabephase nach dem synchronen Close
+- `rmSync` mit 20 Wiederholungen und 100 ms Wartezeit für kurzzeitige Windows-Dateisperren
+- Cleanup-Fehler werden mit Pfad und Fehlercode gemeldet
+- drei isolierte Wiederholungsläufe prüfen, dass kein Temp-Ordner zurückbleibt
+
+Der Fehler tritt vor Pull Request, Merge und Coolify-Deployment auf. Produktivdaten waren dadurch nicht betroffen.
@@ -0,0 +1,11 @@
+# Vendoo Production Updater 2.9
+
+Updater 2.9 behebt die Windows-Dateisperren in allen aktiven Verifiern systematisch.
+
+## Änderungen
+
+- Zentraler SQLite-Test-Cleanup mit WAL-Checkpoint, `db.close()` und Windows-tauglichen Löschwiederholungen.
+- Einladungs-, Initialmodul-, Capability- und Architekturtest verwenden denselben Cleanup-Vertrag.
+- Statischer Importgraph-Audit prüft alle aktiven `verify:all`-Verifier auf transitive `lib/db.mjs`-Nutzung.
+- Dynamische Regression führt alle vier datenbanknahen Testklassen jeweils dreimal in getrennten Node-Prozessen aus.
+- Kein Pull Request, Merge oder Deployment bei fehlgeschlagenem Testlauf.
@@ -0,0 +1,40 @@
+# Vendoo Production Updater 3.1
+
+## Architekturwechsel
+
+Updater 3.1 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.1 beginnt mit einem neuen Release-Branch und einer neuen, versionsgebundenen Sitzung.
@@ -0,0 +1,48 @@
+# 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.
@@ -0,0 +1,17 @@
+# Vendoo Production Updater 3.3
+
+## Zweck
+
+Updater 3.3 behält das manifestbasierte Overlay von 3.2 bei und korrigiert das letzte plattformspezifische Release-Gate.
+
+## Installer-Shell-Portabilität
+
+- Unter Linux, NAS und VPS muss `.env` nach der Erzeugung weiterhin exakt POSIX-Modus `0600` besitzen.
+- Unter Windows prüft Git Bash ausschließlich die Syntax von `setup.sh` und dem funktionalen Shell-Test. Die vollständige Docker-/NAS-/VPS-Simulation läuft im verpflichtenden Linux-CI-Gate, wo POSIX-Rechte real abgebildet werden.
+- Der Shell-Test erkennt MINGW, MSYS und CYGWIN ausdrücklich.
+- Jede fehlgeschlagene Assertion zeigt die betroffene Ausgabe- oder Konfigurationsdatei vollständig an.
+- Der Node-Wrapper reicht `stdout` und `stderr` im Fehlertext weiter.
+
+## Unveränderte Sicherheitsgrenzen
+
+Das SHA-256-Manifest, die bytegeprüfte Steuerdatei, explizite Löschungen, GitHub-PR-/Merge-Gates, Coolify Auto Deploy und `/readyz` bleiben verpflichtend.
@@ -0,0 +1,50 @@
+# Vendoo 1.42.0 – Production Operations & Controlled Update Completion
+
+## Ziel
+
+Version 1.42.0 vervollständigt den sicheren Coolify-Produktionsbetrieb. Ein HTTP-Erfolg des Deploy-Triggers gilt nicht mehr als erfolgreiches Deployment. Ein Auftrag durchläuft persistent gespeicherte Zustände und wird erst nach bestätigtem Deployment, erfolgreicher Readiness und passender Zielversion abgeschlossen.
+
+## Neue Betriebsfunktionen
+
+- Produktionsstatus mit Version, Build-Revision, Provider, öffentlicher URL, Readiness, SQLite-Status, Speicherbelegung, letztem verifiziertem Backup, letztem Deployment und FLUX-Status.
+- Produktions-Selbstprüfung für HTTPS, Cookies, Trust Proxy, Host/Origin, Persistenz, Schreibrechte, SQLite, Backupziel, FLUX, Auto Deploy und Coolify-Secrets.
+- Persistente Deployment-State-Machine mit Ereignisverlauf.
+- Idempotency-Key und Sperre gegen parallele Aufträge.
+- Verifiziertes Vorab-Backup vor dem Coolify-Trigger.
+- Coolify-API-Statusabfrage oder kontrollierter Webhook-Modus mit exakter Bestätigung `CONFIRM`.
+- `/readyz`- und Zielversionsprüfung vor dem Status `succeeded`.
+- `rollback_required` bei Timeout oder Coolify-Fehler; neue Aufträge bleiben bis zur dokumentierten Prüfung gesperrt.
+- Einladungsübersicht, 48-Stunden-Ablauf, erneutes Senden und Widerruf; Standardrolle ist `viewer`.
+
+## Additive Datenbankmigration
+
+Neu angelegt werden ausschließlich:
+
+- `deployment_runs`
+- `deployment_events`
+- `backup_verifications`
+- `production_checks`
+
+Bestehende Tabellen, Nutzer, Artikel, Uploads, Einstellungen, Secrets, Backups und Module werden nicht gelöscht oder zurückgesetzt.
+
+## Neue administrative API-Verträge
+
+- `GET /api/admin/deployment`
+- `PUT /api/admin/deployment`
+- `POST /api/admin/deployment/test`
+- `POST /api/admin/deployment/updates/check`
+- `POST /api/admin/deployment/trigger`
+- `GET /api/admin/deployment/runs`
+- `GET /api/admin/deployment/runs/:id`
+- `POST /api/admin/deployment/runs/:id/refresh`
+- `POST /api/admin/deployment/runs/:id/confirm`
+- `GET|POST /api/admin/deployment/production-check`
+- `GET /api/admin/users/invitations`
+- `POST /api/admin/users/invitations/:id/resend`
+- `DELETE /api/admin/users/invitations/:id`
+
+Alle schreibenden Routen bleiben CSRF-geschützt, rollenbasiert und auditierbar. Secretwerte werden nicht zurückgegeben.
+
+## Sicherheitsgrenzen
+
+Vendoo 1.42.0 besitzt weiterhin keinen Docker-Socket und führt im Produktivcontainer weder `git pull`, `npm install`, Docker-Kommandos noch eine Selbstüberschreibung aus. Coolify bleibt für Build, Containerwechsel und Rollback verantwortlich.
@@ -0,0 +1,12 @@
+# Vendoo 1.43.0
+
+## Schwerpunkt
+
+- Modulstatus und Navigation sind verbindlich gekoppelt.
+- Das optionale Produktbild Studio ist standardmäßig deaktiviert.
+- Der Listing-Generator besitzt eine dauerhaft sichtbare Aktionsleiste.
+- `UPDATE_VENDOO.bat` startet eine grafische Statusanzeige mit Live-Protokoll.
+
+## Sicherheitsgrenzen
+
+Der Updater verändert weiterhin keine produktiven Daten unter `/app/data`, überträgt keine `.env`-Dateien und meldet erst nach erfolgreicher `/readyz`-Zielversionsprüfung Erfolg.
@@ -0,0 +1,44 @@
+# Vendoo 1.42.0 – Restore- und Notfall-Runbook
+
+## Grundsatz
+
+Ein Restore ist keine normale Weboperation. Das laufende Vendoo darf seine geöffnete SQLite-Datenbank nicht im Hintergrund überschreiben. Die Weboberfläche prüft und staged ein Backup; das tatsächliche Einspielen erfolgt im Wartungsfenster bei gestoppter Anwendung.
+
+## Restore-Dry-Run
+
+1. **Administration → System → Backup & Restore** öffnen.
+2. Gewünschtes Backup zuerst mit **Prüfen** validieren.
+3. SHA-256, Manifest, Dateigröße und SQLite-Integrität müssen stimmen.
+4. Für ein extern bereitgestelltes ZIP **Wiederherstellung prüfen und vorbereiten** verwenden.
+5. Vendoo erstellt vor dem Staging automatisch ein zusätzliches Sicherheitsbackup.
+6. Fehlerhafte, unvollständige oder verbotene Pakete nicht manuell entpacken.
+
+## Wartungsrestore
+
+1. Wartungsfenster ankündigen und Benutzer abmelden.
+2. Coolify-Anwendung stoppen; keine zweite Instanz starten.
+3. Vollständiges Volume `/app/data` zusätzlich auf Host-/NAS-Ebene sichern.
+4. Besonders zusammen sichern:
+   - `/app/data/db/vendoo.db` samt möglicher `-wal`/`-shm`-Dateien
+   - `/app/data/uploads`
+   - `/app/data/config/master.key`
+   - `/app/data/config/secrets.enc.json`
+   - `/app/data/config/vendoo.env`
+   - `/app/data/config/modules-state.json`
+5. Nur das verifizierte, vorbereitete Restore anwenden.
+6. Eigentümer und Schreibrechte des nicht privilegierten Containers erhalten.
+7. Anwendung mit exakt einer Instanz starten.
+8. `/readyz`, SQLite-Integrität, Login, Benutzer, Artikel, Uploads, Module und Audit prüfen.
+
+## Reiner Anwendungsrollback
+
+Bei fehlerhaftem Code-Release normalerweise keinen Datenrestore durchführen. In Coolify die vorherige Revision beziehungsweise das vorherige Image redeployen und dasselbe `/app/data`-Volume verwenden.
+
+## Verboten
+
+- `/app/data` löschen
+- neues leeres Volume anhängen
+- zwei schreibende Container auf demselben SQLite-Volume starten
+- die Datenbank bei laufendem Vendoo ersetzen
+- `master.key` neu erzeugen, solange bestehende verschlüsselte Secrets benötigt werden
+- ungeprüfte ZIP-Dateien direkt in das Volume kopieren
@@ -0,0 +1,14 @@
+# Vendoo 1.43.0 – Updater-Hotfix H1
+
+## Behoben
+
+- Endloses Warten direkt nach „Node.js LTS gefunden“.
+- Falsche Erkennung des Windows-App-Execution-Alias als echte Node.js-Installation.
+- Node.js-Versionsprüfung besitzt jetzt ein hartes Timeout von 20 Sekunden.
+- Eine blockierte oder defekte Node.js-LTS-Installation wird über Winget automatisch repariert.
+- Der grafische Updater zeigt Laufzeit und Zeit seit der letzten Statusmeldung.
+- PowerShell- und Prozessausgabe verwenden konsistent UTF-8; deutsche Umlaute werden korrekt dargestellt.
+
+## Sicherheitsgrenze
+
+Bis zum Abschluss der lokalen Prüfungen wird weder nach `main` gemergt noch ein Coolify-Deployment gestartet.
@@ -0,0 +1,16 @@
+# Vendoo 1.43.0 – Updater Hotfix H2
+
+## Behobener Fehler
+
+Nach einer erfolgreichen Erstinstallation der GitHub CLI brach der Ein-Klick-Updater mit der Aufforderung ab, `UPDATE_VENDOO.bat` erneut zu starten. Ursache war, dass die laufende Windows-PowerShell-Sitzung den neu installierten Pfad noch nicht zuverlässig aufgelöst hatte.
+
+## Neue Funktionsweise
+
+- Der Updater aktualisiert den Prozess-PATH nach der Winget-Installation.
+- Er wartet kontrolliert bis zu 30 Sekunden auf die Registrierung der Programmdatei.
+- Zusätzlich werden die offiziellen Installationspfade der GitHub CLI direkt geprüft.
+- Gefundene Programme werden über ihren absoluten Pfad ausgeführt.
+- Nach der Installation läuft derselbe Updatevorgang ohne zweiten Doppelklick weiter.
+- Ein echter Abbruch erfolgt nur, wenn die installierte Programmdatei auch über die bekannten Pfade nicht auffindbar ist.
+
+Produktcode und Datenbankschema bleiben gegenüber Vendoo 1.43.0 unverändert.