Vendoo 1.41.2 – Git Ignore Boundary & Module Tracking Hotfix (#18)
* docs: prepare Vendoo 1.41.2 git-ignore boundary hotfix * fix: track native source modules with root-anchored runtime ignores
This commit was merged in pull request #18.
This commit is contained in:
Masterluke77
@@ -0,0 +1,60 @@
|
||||
# Vendoo 1.32.0 – Abnahmebericht
|
||||
|
||||
**Release:** Docker, NAS & Production Deployment Foundation
|
||||
**Prüfdatum:** 09.07.2026
|
||||
**Ausgangsbasis:** `Vendoo_Feature_1_31_0_Multiuser_Security_Foundation.zip`
|
||||
**Basis-SHA-256:** `cad2670d663c98964b7c3b4e95e5f6e475a3bcae12921339a0a84576b77d325b`
|
||||
|
||||
## Ergebnis
|
||||
|
||||
Vendoo 1.32.0 ist als vollständiges Drüberkopierpaket erstellt. Die Code-, Migrations-, Pfad-, Sicherheits- und Paketprüfungen sind bestanden. Die reale Docker-/NAS-, Windows- und Browser-End-to-End-Abnahme konnte in der bereitgestellten Linux-Sandbox nicht ausgeführt werden, weil dort weder Docker noch PowerShell/Windows noch ein Browser zur Verfügung stehen und das native `better-sqlite3`-Modul in dieser stark begrenzten Build-Umgebung nicht innerhalb des Ausführungszeitlimits kompiliert werden konnte.
|
||||
|
||||
Der Release ist deshalb **für Installation und reale Umgebungsabnahme vorbereitet**, aber Docker-, Windows- und Browserbetrieb werden nicht fälschlich als praktisch getestet ausgewiesen.
|
||||
|
||||
## Bestandene Prüfungen
|
||||
|
||||
| Prüfung | Status | Ergebnis/Nachweis |
|
||||
|---|---|---|
|
||||
| Handover-Reihenfolge | bestanden | `00_START_HIER.md` bis `14_SOURCE_PACKAGE_CHECKSUM.txt` vollständig in vorgegebener Reihenfolge gelesen |
|
||||
| Basis-ZIP SHA-256 | bestanden | stimmt exakt mit Handover überein |
|
||||
| Basis-Dateiprüfsummen | bestanden | 271 von 271 Dateien `OK` |
|
||||
| Reale 1.31.0-Codeanalyse | bestanden | RBAC, Sessions, Audit, Locks, Setup, Windows-Menü, FLUX-Trennung und reale Deployment-Lücken geprüft |
|
||||
| Versionssynchronität | bestanden | Paket, Lockfile, Manifest, UI-Build und Windows-Setup = `1.32.0` |
|
||||
| JS-/MJS-Syntax | bestanden | alle geänderten Laufzeitdateien sowie Verifikator mit `node --check` |
|
||||
| Shell-Syntax | bestanden | Entry-Point, Backup und Restore mit `sh -n` |
|
||||
| YAML-Syntax | bestanden | `compose.yaml` und Bind-Mount-Override mit PyYAML geladen |
|
||||
| Datenbankmigration frisch | bestanden | 68 additive DB-Ausführungsblöcke; Pflichttabellen vorhanden |
|
||||
| Datenbankmigration bestehend | bestanden | vorhandener Testdatensatz blieb erhalten; Publishing- und Operations-Struktur gültig |
|
||||
| Lockfile-Auflösung | bestanden | sauberer `npm ci --ignore-scripts`: 151 Pakete installiert |
|
||||
| Laufzeitpfade | bestanden | DB, Uploads, Backups, Operations und Logs in getrenntem temporären Datenbereich beschreibbar |
|
||||
| Setup-Token Entry-Point | bestanden | fehlender Token beendet Produktion mit Exit 78; 32-Zeichen-Token akzeptiert |
|
||||
| Deployment-Gate | bestanden | Version, Pfadtrennung, Readiness, Shutdown, Setup-Schutz, Origins, Container-Härtung und Datenhygiene |
|
||||
| Datenhygiene | bestanden | keine `.env`, DB, Logs, Uploads, Backups, Operations, Modelle oder `node_modules` im Anwendungspaket |
|
||||
| Secret-Musterscan | bestanden | keine erkannten privaten Schlüssel, AWS- oder `sk-`-Live-Schlüssel |
|
||||
| FLUX/VTO-Regel | bestanden | FLUX bleibt getrennt; Hauptcontainer standardmäßig deaktiviert; freier Workflow ohne `LoadImage`; kein VTO-Wiedereinbau |
|
||||
| Originalbildschutz | bestanden | geänderte Pfadlogik erzeugt keine destruktive Originalüberschreibung |
|
||||
|
||||
## Nicht ausgeführte beziehungsweise nicht vollständig ausführbare Prüfungen
|
||||
|
||||
| Prüfung | Status | Grund |
|
||||
|---|---|---|
|
||||
| vollständiges `npm ci` mit nativen Install-Skripten | nicht abgeschlossen | Registry-/GitHub-Prebuild war nicht verfügbar; lokaler `better-sqlite3`-Fallback kompilierte in der Sandbox auch nach 5 bzw. 10 Minuten nicht fertig |
|
||||
| Serverstart und API-Smoke-Test | nicht ausgeführt | natives `better-sqlite3`-Binary dadurch nicht verfügbar |
|
||||
| Docker-Build | nicht ausgeführt | `docker` ist in der Sandbox nicht installiert (`exit 127`) |
|
||||
| `docker compose config` über Docker CLI | nicht ausgeführt | Docker fehlt; YAML wurde statisch erfolgreich validiert |
|
||||
| Container-Healthcheck/Persistenz/Backup/Restore | nicht ausgeführt | Docker fehlt; Skripte und Mount-Logik wurden statisch geprüft |
|
||||
| Reverse-Proxy-/HTTPS-Livetest | nicht ausgeführt | keine Proxy-/TLS-Laufzeit vorhanden |
|
||||
| Windows-Start/Update | nicht ausgeführt | kein Windows und kein PowerShell vorhanden; reale Menüpunkte 2 und 3 statisch bestätigt |
|
||||
| Login, Session, Logout, Rollen, Upload, Artikel, SmartCopy, Publish-Center | nicht ausgeführt | Server-/Browserlaufzeit nicht verfügbar |
|
||||
| Dark Mode, Responsive, Tastatur/Fokus | nicht ausgeführt | kein Browser-End-to-End-Test; dieser Slice verändert keine Haupt-UI-Layouts, nur das Setup-Token-Feld im Login |
|
||||
| echte Plattform-APIs | nicht ausgeführt | bewusst keine Veröffentlichung ausgelöst |
|
||||
|
||||
## Reale Abnahme nach Installation
|
||||
|
||||
Der Betreiber muss die in `INSTALLATION_1_32_0_WINDOWS_DOCKER_NAS.md` beschriebene Funktionsprüfung ausführen. Besonders wichtig sind `/readyz`, Login/Logout, Rollen, bestehende Artikel und Bilder, Upload, Containerneustart, Testbackup, Restore in einem sicheren Testpfad sowie ein Reverse-Proxy-Test mit HTTPS.
|
||||
|
||||
## Bekannte Folgepunkte
|
||||
|
||||
- Widerrufbare, minimale Browser-Extension-Tokenkopplung statt dauerhafter Cookie-Abhängigkeit bleibt ein späterer Security-Slice.
|
||||
- Offline-Notfallverfahren für den verlorenen letzten Administrator bleibt ein späterer Operations-Slice.
|
||||
- Ein veröffentlichtes, signiertes Container-Image und automatisierte CI-Builds sind noch nicht Bestandteil dieses Pakets.
|
||||
@@ -0,0 +1,34 @@
|
||||
# Vendoo 1.33.0 – Abnahmebericht
|
||||
|
||||
**Release:** Multiplatform Deployment Wizard & Flux/Admin Fixes
|
||||
**Prüfdatum:** 09.07.2026
|
||||
**Basis:** Vendoo 1.32.0
|
||||
|
||||
## Bestandene statische Prüfungen
|
||||
|
||||
- Versionsgleichstand in Paket, Lockfile, UI, Compose, Manifest und Windows-Setup
|
||||
- JavaScript-/MJS-Syntax der geänderten Dateien
|
||||
- POSIX-Shell-Syntax von `setup.sh`
|
||||
- Deployment-Gate 1.33.0
|
||||
- Windows-Assistent enthält alle vier Zieltypen
|
||||
- Linux-Assistent enthält Docker-, NAS- und VPS-Modus
|
||||
- Compose behält non-root, read-only, Healthcheck und getrennte Volumes
|
||||
- FLUX-Historie wählt beim Laden kein Bild mehr automatisch aus
|
||||
- Reset-Funktion löscht weder Verlauf noch Bilder noch Jobs
|
||||
- Benutzeraktionen verwenden gebundene Event-Listener
|
||||
- Passwortvalidierung findet vor dem Benutzer-Update statt
|
||||
- Benutzer-Update liefert einen sanitiserten Datensatz
|
||||
- keine produktive `.env`, DB, Uploads, Backups, Logs, Operations oder `node_modules` im Release
|
||||
|
||||
## Nicht als praktisch getestet ausgewiesen
|
||||
|
||||
- Windows PowerShell 5.1 Laufzeit, da die Sandbox kein Windows/PowerShell enthält
|
||||
- Docker-Build und Containerstart, da kein Docker-Daemon vorhanden ist
|
||||
- Portainer-Import und herstellerspezifische NAS-Oberflächen
|
||||
- realer VPS-Reverse-Proxy und TLS
|
||||
- Browser-End-to-End-Klicktest
|
||||
- native Serverlaufzeit mit `better-sqlite3`
|
||||
|
||||
## Abnahmeentscheidung
|
||||
|
||||
Das Paket ist als Drüberkopier-Release und als geführte Installationsgrundlage vorbereitet. Die reale Zielsystemabnahme muss nach `02_INSTALLATION_UND_ABNAHME.md` erfolgen. Kein nicht ausgeführter Laufzeittest wird als bestanden dargestellt.
|
||||
@@ -0,0 +1,50 @@
|
||||
# Vendoo 1.34.0 – Abnahmebericht
|
||||
|
||||
**Release:** GitHub CI/CD & Zero-Edit Installer Foundation
|
||||
**Prüfdatum:** 09.07.2026
|
||||
**Basis:** Vendoo 1.33.0
|
||||
|
||||
## Umgesetzte Abnahmepunkte
|
||||
|
||||
- geführte Windows-Installationsmaske für lokalen Betrieb und Docker Desktop,
|
||||
- geführter Shell-Assistent für Linux, macOS, NAS/Portainer und VPS,
|
||||
- keine manuelle Bearbeitung von `.env`, Compose oder Caddy-Konfiguration erforderlich,
|
||||
- automatisch erzeugter Erst-Admin-Code,
|
||||
- Eingabevalidierung für Port, URL und Domain,
|
||||
- automatisches VPS-HTTPS über getrennten Caddy-Stack,
|
||||
- persistenter Runtime-Konfigurationsspeicher für Einstellungen im read-only Container,
|
||||
- CI für reproduzierbare Installation, Syntax, Migrationen, Git-Sicherheit, Compose und Docker-Testbuild,
|
||||
- Release-Automation für ZIP, SHA-256 und GHCR-Images,
|
||||
- kontrollierter Git-Erstimport mit lokalem Sicherheitsgate,
|
||||
- real angelegter Branch `release/1.34.0-initial-import`,
|
||||
- real angelegter Draft Pull Request #3.
|
||||
|
||||
## Bestandene Prüfungen
|
||||
|
||||
- JavaScript-/MJS-Syntaxprüfung,
|
||||
- POSIX-Shell-Syntaxprüfung,
|
||||
- simulierte Installationsläufe für Docker lokal, NAS-Bind-Mount und VPS/Caddy,
|
||||
- dabei erkannter und behobener Standardwert-/Prompt-Fehler im Shell-Assistenten,
|
||||
- YAML-Parsing aller Compose- und GitHub-Workflow-Dateien,
|
||||
- Deployment-Gate 1.34.0,
|
||||
- Git-Sicherheitsgate,
|
||||
- Datenbankmigrationstest gegen frische und bestehende Testdatenbank,
|
||||
- bestehender Testdatensatz blieb erhalten,
|
||||
- persistenter Konfigurationsspeicher einschließlich Dateirechten und Mehrzeilen-Sperre,
|
||||
- Versionsgleichstand von Paket, Lockfile, UI, Manifest, Compose und Installer,
|
||||
- kein produktives Secret oder Laufzeitdatum im bereinigten Release.
|
||||
|
||||
## Nicht als praktisch getestet ausgewiesen
|
||||
|
||||
- tatsächlicher WinForms-/PowerShell-5.1-Lauf auf Windows,
|
||||
- Docker-Build und Containerstart mit realem Docker-Daemon,
|
||||
- Docker Desktop auf Windows/macOS,
|
||||
- Portainer-Import auf einem realen NAS,
|
||||
- Caddy-Zertifikatsausstellung mit echter Domain und öffentlichem DNS,
|
||||
- Browser-End-to-End-Abnahme,
|
||||
- vollständige native Node-Laufzeit mit kompiliertem `better-sqlite3`,
|
||||
- veröffentlichter GitHub-Release-Workflow und GHCR-Push.
|
||||
|
||||
## Abnahmeentscheidung
|
||||
|
||||
Das Release ist als vollständiges Drüberkopier-Paket, Zero-Edit-Installationsgrundlage und kontrollierte GitHub-Importbasis freigegeben. Zielsystemtests bleiben gemäß Installations- und Abnahmeanleitung verpflichtend. Nicht ausgeführte Laufzeittests werden nicht als bestanden dargestellt.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Vendoo 1.34.1 – Abnahmebericht
|
||||
|
||||
## Bestanden
|
||||
|
||||
- JavaScript-Syntax des Git-Sicherheitsgates und des Regressionstests
|
||||
- vollständiger Arbeitsbaumscan auf sauberem Release-Quellstand
|
||||
- Blockierung unversionierter `.env.local`- und Token-Testdateien
|
||||
- erfolgreicher Lauf nach Entfernung der Test-Secrets
|
||||
- Deployment-Gate 1.34.1
|
||||
- Shell-Syntax des Linux/macOS-Deploy-Assistenten
|
||||
- Versionsgleichstand in Paket, Lockfile, UI, Setup und Manifest
|
||||
- GitHub-Branch `release/1.34.1-initial-import` und Draft Pull Request #4 real angelegt
|
||||
- Pull Request #3 geschlossen und als ersetzt dokumentiert
|
||||
|
||||
## Nicht als real getestet ausgewiesen
|
||||
|
||||
- vollständiger Lauf unter Windows PowerShell 5.1
|
||||
- echte Browser-Anmeldung und kompletter Push vom Nutzer-PC
|
||||
- GitHub Actions nach vollständigem Quellimport
|
||||
- Docker-/NAS-/VPS-Laufzeit, da dieser Hotfix ausschließlich das Git-Sicherheitsgate betrifft
|
||||
@@ -0,0 +1,25 @@
|
||||
# Vendoo 1.34.2 – Abnahmebericht
|
||||
|
||||
## Bestanden
|
||||
|
||||
- JavaScript-Syntax von Staging-Builder, Staging-Regressionstest, Sicherheitsgate und Deployment-Gate
|
||||
- Shell-Syntax des Linux/macOS-Deploy-Assistenten
|
||||
- YAML-Parsing von CI, Release und Compose-Dateien
|
||||
- Git-Staging-Regressionstest: sichere Dateien kopiert, lokale `.env.local`, Operations-, Log-, Upload-, DB- und Modelltestdaten ausgeschlossen
|
||||
- `.git` des temporären Klons blieb unverändert erhalten
|
||||
- Git-Sicherheitsgate auf dem vollständigen Release-Quellstand
|
||||
- Secret-Regressionstest mit unversionierten Testdateien
|
||||
- Deployment-Gate 1.34.2
|
||||
- Shell-Installer-Simulation für Docker, NAS und VPS
|
||||
- Datenbankmigrationen: 68 Einheiten auf frischer und bestehender Datenbank
|
||||
- vorhandener Testdatensatz blieb erhalten
|
||||
- Versionsgleichstand in Paket, Lockfile, UI, Setup, Compose und Update-Manifest
|
||||
|
||||
## Nicht als real getestet ausgewiesen
|
||||
|
||||
- vollständiger Lauf unter Windows PowerShell 5.1
|
||||
- echte GitHub-Browseranmeldung und kompletter Push vom Nutzer-PC
|
||||
- GitHub Actions nach vollständigem Quellimport
|
||||
- echter Docker-/NAS-/VPS-Lauf
|
||||
|
||||
Die Windows-spezifische Prozessausgabe wurde statisch geprüft; eine echte Windows-Laufzeit steht in der Erstellungsumgebung nicht zur Verfügung.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Vendoo 1.34.3 – Abnahmebericht
|
||||
|
||||
## Bestanden
|
||||
|
||||
- Staging-Regression mit `updates/backups/slice22_1_20260707-194953/scripts/install-local-flux.ps1`
|
||||
- Staging-Regression mit `updates/backups/slice22_1_20260707-194953/setup.bat`
|
||||
- Staging-Regression mit `updates/backups/slice22_1_20260707-194953/setup.ps1`
|
||||
- aktive Root-/scripts-Installationsdateien bleiben im Staging
|
||||
- Git-Sicherheitsgate auf bereinigtem Quellstand
|
||||
- JavaScript-/MJS-Syntaxprüfung
|
||||
- Deployment-Gate 1.34.3
|
||||
- Shell-Installer-Simulation
|
||||
- Datenbankmigrationsprüfung gegen frische und bestehende Testdatenbank
|
||||
|
||||
## Nicht als real getestet
|
||||
|
||||
- Windows PowerShell 5.1 auf dem Benutzerrechner
|
||||
- echter Push aus dem lokalen Projektordner
|
||||
- Docker-/Portainer-/VPS-Livetest
|
||||
- GitHub-Actions-Lauf nach dem vollständigen Import
|
||||
@@ -0,0 +1,53 @@
|
||||
# Vendoo 1.35.0 – Abnahmebericht
|
||||
|
||||
## Bestanden
|
||||
|
||||
- JavaScript-/MJS-Syntax aller bestehenden und neuen Kernbestandteile
|
||||
- Plattform-Architecture-Gate
|
||||
- zwölf Modulmanifeste und Abhängigkeiten
|
||||
- Zykluserkennung
|
||||
- fehlende Capability wird blockiert
|
||||
- doppelte Ressourcen-Ownership wird blockiert
|
||||
- Deny-by-default-Route ohne Policy wird blockiert
|
||||
- nicht berechtigter Zugriff auf registrierte Route ergibt HTTP 403
|
||||
- Event-Auslieferung und Owner-Cleanup
|
||||
- Lifecycle- und Modulshutdown
|
||||
- sichere Theme-Werte und verbotene Token
|
||||
- RGB-Bereichsprüfung
|
||||
- deterministische Token-Generierung
|
||||
- Light, Dark und High Contrast vorhanden
|
||||
- Safe-DOM-Vertrag ohne `innerHTML`
|
||||
- API-Client-Vertrag mit CSRF und Same-Origin
|
||||
- Deployment-Gate 1.35.0
|
||||
- Git-Sicherheitsgate: 365 Dateien ohne Secrets/Laufzeitdaten
|
||||
- Git-Sicherheits-Regressionstest
|
||||
- Git-Staging-Regressionstest
|
||||
- persistenter Konfigurationsspeicher
|
||||
- Shell-Installer-Simulation für Docker, NAS und VPS
|
||||
- 68 Migrationseinheiten gegen frische Datenbank
|
||||
- 68 Migrationseinheiten gegen bestehende Datenbank
|
||||
- vorhandener Testdatensatz blieb erhalten
|
||||
|
||||
## Dependency-Test
|
||||
|
||||
`npm ci` wurde versucht. Die Lockdatei wurde aufgelöst, aber `better-sqlite3` konnte in der Sandbox nicht fertig gebaut werden:
|
||||
|
||||
1. Prebuild-Download scheiterte wegen fehlender DNS-/Netzverbindung zu GitHub.
|
||||
2. Der Fallback mit lokal vorhandenen Node-Headern begann erfolgreich zu kompilieren, wurde aber beim SQLite-C-Build durch das Ausführungslimit beendet.
|
||||
|
||||
Dieser Punkt wird nicht als bestanden ausgegeben.
|
||||
|
||||
## Nicht praktisch getestet
|
||||
|
||||
- Windows PowerShell 5.1 und WinForms
|
||||
- echter Windows-Lokalstart
|
||||
- echter Docker-/NAS-/Portainer-Start
|
||||
- VPS/Caddy/TLS
|
||||
- Browser-End-to-End-Test
|
||||
- visuelle Regression aller Seiten
|
||||
- vollständiger Node-Serverstart mit nativ kompiliertem `better-sqlite3`
|
||||
- GitHub Actions und GHCR-Liveausführung
|
||||
|
||||
## Daten- und Kompatibilitätsaussage
|
||||
|
||||
Keine Datenbank, Uploads, Backups, Operations-Daten, Benutzer, Artikel, API-Schlüssel, FLUX-Modelle oder ComfyUI-Daten wurden in das Paket aufgenommen oder gelöscht. Es gibt keine Framework- oder Datenbankmigration.
|
||||
@@ -0,0 +1,32 @@
|
||||
# Abnahmebericht Vendoo 1.36.0
|
||||
|
||||
## Gegenstand
|
||||
|
||||
Secure Theme Manager, Accessibility & Component Token Foundation.
|
||||
|
||||
## Erfolgreich geprüft
|
||||
|
||||
- JavaScript-/MJS-Syntax
|
||||
- Plattform-Architektur und zwölf Modulmanifeste
|
||||
- natives Theme-Modul
|
||||
- 42 Design Tokens und drei integrierte Themes
|
||||
- Theme-Validierung und ungültige CSS-/Script-Werte
|
||||
- Deny-by-default Theme-Routen
|
||||
- Benutzer-/Administrator-Policy-Trennung
|
||||
- Theme-Tabellen auf frischer und bestehender Datenbank
|
||||
- Git-Sicherheitsgate mit 385 geprüften Dateien und Staging-Filter
|
||||
- Windows-/Docker-/NAS-/VPS-Deploymentverträge
|
||||
- reproduzierbare Paketauflösung mit 151 Paketen über `npm ci --ignore-scripts`
|
||||
- Release-Staging mit 384 Einzeldatei-Prüfsummen
|
||||
|
||||
## Nicht als real ausgeführt gewertet
|
||||
|
||||
- Browser-End-to-End-Test unter echtem Windows
|
||||
- Docker-/NAS-/VPS-Livestart
|
||||
- Caddy-/TLS-Livetest
|
||||
- GitHub-Actions-Livelauf
|
||||
- native Kompilierung/Ausführung von `better-sqlite3` in der Sandbox; `npm ci --ignore-scripts` war erfolgreich, native Installationsskripte wurden bewusst nicht ausgeführt
|
||||
|
||||
## Ergebnis
|
||||
|
||||
Die statische, architektonische und migrationsbezogene Abnahme ist bestanden. Die genannten plattformspezifischen Laufzeittests sind nach Installation in der Zielumgebung durchzuführen.
|
||||
@@ -0,0 +1,3 @@
|
||||
# Abnahmebericht 1.37.0
|
||||
|
||||
Siehe die vollständige Release-Abnahme im Paketroot `04_ABNAHMEBERICHT.md`. Die automatisierten Gates prüfen Secret-Migration, Verschlüsselung, CSP, Request-IDs, Telemetrie, Architektur, Deployment, Installer und Datenbankkompatibilität.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Abnahmebericht Vendoo 1.38.0
|
||||
|
||||
## Ergebnis
|
||||
|
||||
Die statische, architektonische, migrationsbezogene und sicherheitsbezogene Abnahme ist bestanden.
|
||||
|
||||
## Bestanden
|
||||
|
||||
- vierzehn registrierte Module
|
||||
- sechs native Module und acht Legacy Bridges
|
||||
- native Auth-, Benutzer-, Sitzungs- und Settings-Routen
|
||||
- Deny-by-default-Policies und Eingabeschemata
|
||||
- letzter-Admin-Schutz
|
||||
- Eigentümerprüfung beim Widerruf eigener Sitzungen
|
||||
- Settings-Allowlist und Ablehnung unbekannter Felder
|
||||
- spezifische Permissions für SMTP und Login-Historie
|
||||
- Git-Sicherheitsgate einschließlich legitimen Quellmoduls `app/modules/sessions/`
|
||||
- Secret-, Theme-, Architektur-, Deployment-, Konfigurations-, Installer- und DB-Gates
|
||||
- frische und bestehende SQLite-Testdatenbank
|
||||
- vorhandener Testdatensatz blieb erhalten
|
||||
|
||||
## Nicht als praktisch ausgeführt behauptet
|
||||
|
||||
- Browser-End-to-End-Abnahme unter echtem Windows
|
||||
- produktiver Docker-/NAS-/VPS-Start
|
||||
- Caddy-/TLS-Livetest
|
||||
- echte SMTP-, OAuth- und Marktplatzverbindungen
|
||||
- vollständige native `better-sqlite3`-Installation in der Sandbox
|
||||
- GitHub-Actions-Livelauf vor dem vollständigen lokalen Quellpush
|
||||
|
||||
Die native Node-Komponente kann in der Sandbox wegen fehlendem Zugriff auf Prebuilds beziehungsweise Node-Header nicht zuverlässig gebaut werden. Dieser Punkt muss auf dem Zielsystem über `setup.bat` beziehungsweise den Docker-Build geprüft werden.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Abnahmebericht Vendoo 1.39.0
|
||||
|
||||
## Bestanden
|
||||
|
||||
- native Modulverträge für Listings, Inventory und Media
|
||||
- Entfernung der öffentlichen Legacy-Routen aus `server.mjs`
|
||||
- Artikel-Allowlist, Rich-HTML-Sanitizing und Lock-Vertrag
|
||||
- Papierkorbgrenze für endgültiges Löschen
|
||||
- Inventory-Deduplizierung und 500er-Bulk-Limit
|
||||
- Medienpfad- und Artikelreferenzschutz
|
||||
- Dependency Injection ohne Datenbank-Seiteneffekt beim Modulimport
|
||||
- kombinierte Git-, Architektur-, Theme-, Security-, Identity-, Catalog-, Deployment-, Installer- und Datenbank-Gates
|
||||
|
||||
## Nicht als real ausgeführt behauptet
|
||||
|
||||
- Browser-End-to-End-Test auf Windows
|
||||
- nativer `better-sqlite3`-Lauf in dieser Sandbox
|
||||
- Docker-/NAS-/VPS-Livestart
|
||||
- GitHub-Actions-Lauf vor dem vollständigen Quellpush
|
||||
@@ -0,0 +1,22 @@
|
||||
# Abnahmebericht Vendoo 1.40.2
|
||||
|
||||
## Bestanden
|
||||
|
||||
- Syntaxprüfung aller JavaScript-/MJS-/CJS-Dateien
|
||||
- ESM-Import-/Export-Vertragsprüfung
|
||||
- FLUX-Worker-Lifecycle-Gate
|
||||
- Capability-Graph-Gate: 16 Module, 35 Capabilities
|
||||
- Plattformarchitektur, Theme, Security, Identity, Catalog und Modulmanager
|
||||
- Git-Sicherheitsgate und Regressionstests
|
||||
- Git-Staging-Regression
|
||||
- Deployment-, Konfigurations- und Installer-Gates
|
||||
- 68 Migrationsblöcke auf frischer und bestehender Datenbank
|
||||
- vorhandener Testdatensatz blieb erhalten
|
||||
|
||||
## Nicht als real ausgeführt ausgewiesen
|
||||
|
||||
- echter Windows-/PowerShell-End-to-End-Lauf
|
||||
- Browser-End-to-End-Abnahme
|
||||
- Docker-/NAS-/VPS-Livestart
|
||||
- GitHub-Actions-Livelauf vor dem vollständigen Quellpush
|
||||
- native `better-sqlite3`-Kompilierung in dieser Sandbox
|
||||
@@ -0,0 +1,64 @@
|
||||
# Abnahmebericht Vendoo 1.41.0
|
||||
|
||||
## Ergebnis
|
||||
|
||||
Die statischen, architektonischen, sicherheitsbezogenen, migrationsbezogenen und paketbezogenen Prüfungen sind erfolgreich. Der tatsächliche Docker-Build und die öffentliche Domainabnahme erfolgen anschließend über GitHub Actions und Coolify, weil in der Paketumgebung kein Docker-Daemon verfügbar war.
|
||||
|
||||
## Bestandene Gates
|
||||
|
||||
- Git-Sicherheitsgate und Secret-Regression
|
||||
- bereinigtes Git-Staging
|
||||
- JavaScript-/MJS-/CJS-Syntax
|
||||
- lokale ESM-Import-/Export-Verträge
|
||||
- FLUX-Worker-Lifecycle
|
||||
- vollständiger Capability-Graph
|
||||
- Coolify-Deploymentservice
|
||||
- FLUX-Initialstatus und persistente Adminentscheidung
|
||||
- Plattformarchitektur
|
||||
- Theme Manager
|
||||
- Security Foundation
|
||||
- Auth, Benutzer, Sitzungen und Settings
|
||||
- Listings, Inventory und Media
|
||||
- sicherer Modulmanager
|
||||
- Deployment- und Releaseverträge
|
||||
- persistenter Konfigurationsspeicher
|
||||
- Shell-Installer für Docker, NAS und VPS
|
||||
- Datenbankmigrationen auf frischer und bestehender Datenbank
|
||||
- reproduzierbare Lockfile-Auflösung
|
||||
- Compose-YAML-Prüfung
|
||||
|
||||
## Bestätigte Plattformwerte
|
||||
|
||||
- Version: `1.41.0`
|
||||
- Module: 17
|
||||
- native Module: 15
|
||||
- Legacy Bridges: 2
|
||||
- Capabilities: 38
|
||||
- Datenbank-Migrationsblöcke: 68 auf frischer und 68 auf bestehender Datenbank
|
||||
- vorhandener Testdatensatz: erhalten
|
||||
- npm-Lockfile-Auflösung: 151 Pakete
|
||||
|
||||
## Sicherheitsbestätigungen
|
||||
|
||||
- kein Docker-Socket im Containervertrag
|
||||
- kein selbstständiges `git pull` oder Containerüberschreiben
|
||||
- Coolify-Secrets ausschließlich im verschlüsselten Secret Store
|
||||
- Deployment nur mit `updates.manage`
|
||||
- CSRF, Rate Limit und Audit für Deploymentrouten
|
||||
- exakte Bestätigung `DEPLOY`
|
||||
- Vorab-Backup standardmäßig aktiv
|
||||
- HTTPS-Pflicht für Coolify in Produktion
|
||||
- FLUX Studio beim ersten Produktionsstart deaktiviert
|
||||
|
||||
## Noch praktisch zu prüfen
|
||||
|
||||
- vollständiger GitHub-Push auf PR #16
|
||||
- GitHub Actions einschließlich realem Docker-Build
|
||||
- Merge nach `main`
|
||||
- GitHub Release `v1.41.0`
|
||||
- GHCR Multi-Arch-Image
|
||||
- Coolify-Build beziehungsweise Image-Pull
|
||||
- DNS und TLS für `vendoo.flatlined.de`
|
||||
- öffentliches `/readyz`
|
||||
- Login, Benutzer, Artikel, Medien, Backups und Update Center
|
||||
- Coolify-Webhook oder API-Auftrag aus Vendoo
|
||||
@@ -0,0 +1,10 @@
|
||||
# Abnahmebericht Vendoo 1.41.1
|
||||
|
||||
Geprüft werden insbesondere:
|
||||
|
||||
- vier produktive Listings-/Inventory-Pflichtdateien vorhanden
|
||||
- defektes synthetisches `Archiv/.../server.mjs` wird nicht als Source geprüft
|
||||
- fehlende reale Moduldatei wird weiterhin erkannt
|
||||
- Archive werden nicht in Git-Staging und Release-Staging kopiert
|
||||
- vollständige ESM-, Capability-, Coolify-, Modul-, Deployment- und Datenbankgates
|
||||
- keine produktiven Laufzeitdaten im Paket
|
||||
@@ -0,0 +1,6 @@
|
||||
# Abnahmebericht Vendoo 1.41.2
|
||||
|
||||
- Root-verankerte Runtime-Ignores geprüft
|
||||
- `app/modules/listings`, `inventory` und `sessions` werden getrackt
|
||||
- Root-`modules`, `sessions`, `logs`, `backups`, `updates` und `runtime` bleiben ignoriert
|
||||
- Git-Staging, Source-Root, ESM, Capability, Coolify und Datenbankgates geprüft
|
||||
@@ -0,0 +1,33 @@
|
||||
# Vendoo 1.31.0 – Ist- und Lückenanalyse
|
||||
|
||||
Stand der Prüfung: 09.07.2026
|
||||
Geprüfte Basis: `Vendoo_Feature_1_31_0_Multiuser_Security_Foundation.zip`
|
||||
Verifizierte SHA-256 der Basis: `cad2670d663c98964b7c3b4e95e5f6e475a3bcae12921339a0a84576b77d325b`
|
||||
|
||||
Die Bewertung basiert auf dem real enthaltenen Code. Paketnamen und Dokumentation wurden nicht als alleiniger Funktionsnachweis verwendet.
|
||||
|
||||
| Bereich | Status in 1.31.0 | Reale Fundstelle | Risiko/Lücke | Änderung in 1.32.0 |
|
||||
|---|---|---|---|---|
|
||||
| Versionen | bestätigt | `package.json`, Lockfile, UI-Build und Manifest = 1.31.0 | keine | auf 1.32.0 synchronisiert |
|
||||
| Rollen/RBAC | bestätigt | `lib/security.mjs`, globaler `apiPermissionGuard` | einzelne Sonderrouten bleiben zusätzlich manuell zu beobachten | unverändert erhalten |
|
||||
| Sessions/Login-Schutz | bestätigt, Setup-Ausnahme riskant | `lib/auth.mjs`, gehashte Tokens, Sperrlogik, Widerruf; `requireAuth` übersprang im Setup-Modus alle APIs | vor erstem Admin waren geschützte API-Routen unnötig offen; kein Offline-Notfallreset für verlorenen letzten Admin | API im Setup-Modus gesperrt; Notfallreset als Folgepunkt dokumentiert |
|
||||
| CSRF/Cookies | vorhanden | Double-Submit-Cookie und Header, `HttpOnly`, dynamisches `Secure`, `SameSite=lax` | Cookie-Modus nicht konfigurierbar; Proxyannahme nur boolesch/ein Hop | Cookie-Modus konfigurierbar, Proxy-Hops/Scopes unterstützt |
|
||||
| CORS/Origin | vorhanden, unvollständig | Host-/Origin-Middleware in `server.mjs` | jede Browser-Extension-Origin wurde pauschal akzeptiert | in Produktion nur konkrete Extension-Origins, unsicherer Opt-in separat |
|
||||
| Audit/Locks | bestätigt | Audit-Log, `resource_locks`, Adminansicht | keine kritische Deployment-Lücke | erhalten |
|
||||
| Health | teilweise | `/healthz` liefert Prozessstatus | keine Readiness-, DB- oder Schreibpfadprüfung | `/readyz` mit DB- und Volume-Schreibtest |
|
||||
| Shutdown | fehlt | direkter `app.listen()` ohne Signalbehandlung | WAL/Jobs können beim Containerstopp hart beendet werden | SIGTERM/SIGINT, Server-Close, WAL-Checkpoint, DB-Close |
|
||||
| Datenbankpfad | unvollständig | fest `db/vendoo.db` im Codeordner | Container-Image und Nutzerdaten nicht sauber trennbar | `VENDOO_DB_PATH` und zentrale Laufzeitpfade |
|
||||
| Uploadpfad | unvollständig | fest `uploads/` im Codeordner | keine getrennte Persistenz; öffentlich statisch erreichbar | konfigurierbarer Pfad, Zugriff hinter Anmeldung |
|
||||
| Uploadprüfung | Sicherheitsrisiko | Dateiendung **oder** `image/*` genügte | manipulierbarer MIME-Typ konnte beliebige Endungen umgehen | Endung **und** Bild-MIME erforderlich; Größenlimit bleibt aktiv |
|
||||
| Backups | bestätigt, aber codegebunden | verifizierte ZIPs mit DB/Uploads in `operations-center.mjs` | Pfade fest an Projektroot; Live-Volume-Kopie nicht dokumentiert | separate Backup-/Operations-Volumes und sichere Stop/Backup/Start-Anleitung |
|
||||
| Restore/Update | vorhanden, gestuft | Operations Center und `setup.ps1` | Container darf Anwendungscode nicht in-place überschreiben | Docker-Update nur über neues Image; Windows-Update bleibt erhalten |
|
||||
| Docker/Compose | fehlt | keine entsprechenden Dateien | kein reproduzierbarer NAS-/Produktionsbetrieb | Dockerfile, Compose, Healthcheck, non-root, read-only, Volumes |
|
||||
| Reverse Proxy | teilweise | Host/Origin, `PUBLIC_BASE_URL`, `trust proxy` | kein fertiger Produktionsleitfaden | HTTPS-/Proxy-Dokumentation und sichere Standardbindung |
|
||||
| FLUX/ComfyUI | getrennt im Konzept | externer URL-Endpunkt; lokaler Windows-Installer | Bootstrap schreibt in Projektordner und passt nicht zu read-only Container | Container startet standardmäßig ohne FLUX; externer Dienst bleibt optional |
|
||||
| Browser-Erweiterungen | real vorhanden | Chrome/Edge/Firefox/Safari-Strukturen und Pakete | Remote-Kopplung nutzt weiterhin Login-Cookie statt widerrufbarem Extension-Token | CORS gehärtet; Tokenkopplung bleibt geplanter 1.34.0-Slice |
|
||||
| UI-Begriffe/Kernbereiche | weitgehend bestätigt | Navigation, Artikel, Galerie, SmartCopy, Publish und Erweiterungen im realen HTML/JS | vollständige Browser-End-to-End-Abnahme nicht statisch beweisbar | keine unnötige UI-Neuentwicklung in diesem Deployment-Slice |
|
||||
| VTO | entfernt | kein aktiver FASHN-/VTO-Dienst; freier FLUX-Workflow ohne `LoadImage` | historische Dokumente enthalten weiterhin Kontext | keine VTO-Rückkehr |
|
||||
|
||||
## Ergebnis
|
||||
|
||||
1.31.0 besitzt eine echte Mehrbenutzer- und Sicherheitsgrundlage, war aber noch kein sauber containerisierbarer Produktionsstand. Die Hauptlücken lagen in der festen Kopplung von Code und Nutzerdaten, fehlender Readiness, fehlendem geordneten Shutdown, fehlenden Containerdateien sowie zu breiten Extension-Origin- und Uploadregeln.
|
||||
@@ -0,0 +1,23 @@
|
||||
# Vendoo Branding
|
||||
|
||||
Die Anwendung verwendet ab Version 1.6.2 ein gemeinsames Vendoo-Branding für Web-App, Login, mobilen Foto-Upload und Browser-Erweiterungen.
|
||||
|
||||
## Web-App
|
||||
|
||||
Assets liegen unter `public/brand/`:
|
||||
|
||||
- `logo/` – horizontales Logo, transparente und zugeschnittene Varianten
|
||||
- `icons/` – App- und Mobilgrößen von 16 bis 512 Pixel
|
||||
- `favicons/` – ICO, PNG-Favicons, Apple Touch Icon, Android-Icons und Webmanifest
|
||||
|
||||
## Browser-Erweiterungen
|
||||
|
||||
Chrome, Edge und Firefox verwenden dieselbe Icon-Familie in 16, 32, 48 und 128 Pixeln. Popup, Browser-Toolbar, Vinted Assistant und minimierter Assistant verwenden das neue Markenzeichen.
|
||||
|
||||
## Farben
|
||||
|
||||
- Vendoo Orange: `#E63B17`
|
||||
- Graphit: `#22201D`
|
||||
- Warmes Off-White: `#FAF6F2`
|
||||
|
||||
Die Proportionen und Farben der bereitgestellten Assets sollen nicht manuell verändert werden.
|
||||
@@ -0,0 +1,260 @@
|
||||
# Vendoo 1.41.0 – Coolify-Produktionsinstallation
|
||||
|
||||
Zieladresse: `https://vendoo.flatlined.de`
|
||||
|
||||
## Zielarchitektur
|
||||
|
||||
```text
|
||||
GitHub Repository Masterluke77/vendoo
|
||||
│
|
||||
│ Coolify GitHub App
|
||||
▼
|
||||
Coolify Dockerfile Build
|
||||
│
|
||||
▼
|
||||
Vendoo Container :8124
|
||||
│
|
||||
├── Domain/HTTPS durch Coolify
|
||||
└── persistentes Volume /app/data
|
||||
```
|
||||
|
||||
Vendoo erhält keinen Zugriff auf `/var/run/docker.sock`. Deployments werden über einen verschlüsselten Coolify-Webhook oder einen minimal berechtigten Coolify-API-Token angefordert.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- funktionierende Coolify-Installation
|
||||
- öffentlicher Server mit erreichbaren Ports 80 und 443
|
||||
- DNS-Verwaltung für `flatlined.de`
|
||||
- privates GitHub-Repository `Masterluke77/vendoo`
|
||||
- vollständiger Vendoo-1.41.0-Stand im Branch `main`
|
||||
|
||||
## 1. DNS
|
||||
|
||||
Beim DNS-Anbieter einen A-Record anlegen:
|
||||
|
||||
```text
|
||||
Typ: A
|
||||
Name: vendoo
|
||||
Wert: ÖFFENTLICHE_IPV4_DES_COOLIFY_SERVERS
|
||||
TTL: Auto oder 300
|
||||
```
|
||||
|
||||
Nur bei korrekt eingerichtetem IPv6 zusätzlich:
|
||||
|
||||
```text
|
||||
Typ: AAAA
|
||||
Name: vendoo
|
||||
Wert: ÖFFENTLICHE_IPV6_DES_COOLIFY_SERVERS
|
||||
```
|
||||
|
||||
Vor dem Coolify-Deployment prüfen, dass `vendoo.flatlined.de` auf den Coolify-Server zeigt.
|
||||
|
||||
## 2. GitHub-App in Coolify
|
||||
|
||||
1. In Coolify links `Sources` öffnen.
|
||||
2. `Add Source` beziehungsweise `New Source` wählen.
|
||||
3. `GitHub App` wählen.
|
||||
4. Die GitHub-Verknüpfung autorisieren.
|
||||
5. Der App ausschließlich Zugriff auf `Masterluke77/vendoo` geben.
|
||||
6. Verbindung speichern.
|
||||
|
||||
Die GitHub-App ist für private Repositories die bevorzugte Variante, weil Coolify damit Repositoryzugriff, Webhooks und Pull-Request-Deployments verwalten kann.
|
||||
|
||||
## 3. Projekt und Anwendung erstellen
|
||||
|
||||
1. `Projects` öffnen.
|
||||
2. Projekt `Vendoo` erstellen.
|
||||
3. Environment `Production` erstellen.
|
||||
4. `Add Resource` wählen.
|
||||
5. `Private Repository (GitHub App)` wählen.
|
||||
6. Repository `Masterluke77/vendoo` auswählen.
|
||||
7. Branch `main` auswählen.
|
||||
8. Build Pack `Dockerfile` wählen.
|
||||
9. Base Directory `/` eintragen.
|
||||
10. Dockerfile Location `/Dockerfile` eintragen.
|
||||
|
||||
## 4. Netzwerk
|
||||
|
||||
In der Anwendung konfigurieren:
|
||||
|
||||
```text
|
||||
Domain: https://vendoo.flatlined.de
|
||||
Port Exposes: 8124
|
||||
Port Mapping: leer lassen
|
||||
Force HTTPS: aktiviert
|
||||
```
|
||||
|
||||
Kein `8124:8124` Host-Port-Mapping verwenden. Der Coolify-Proxy verbindet sich intern mit Port 8124.
|
||||
|
||||
## 5. Persistentes Volume
|
||||
|
||||
Unter `Storages` oder `Persistent Storage` ein Volume anlegen:
|
||||
|
||||
```text
|
||||
Name: vendoo-data
|
||||
Destination Path: /app/data
|
||||
```
|
||||
|
||||
Nicht mehrere Container gleichzeitig auf dasselbe SQLite-Volume schreiben lassen. Für Vendoo zunächst genau eine laufende Instanz verwenden.
|
||||
|
||||
Im Volume bleiben erhalten:
|
||||
|
||||
- Datenbank
|
||||
- Uploads
|
||||
- Backups
|
||||
- Operations-Daten
|
||||
- verschlüsselte Secrets und Master-Key
|
||||
- Modulstatus und installierte Module
|
||||
- Logs
|
||||
|
||||
## 6. Umgebungsvariablen
|
||||
|
||||
Die Vorlage `deploy/coolify.env.example` verwenden. Für die Domain mindestens folgende Werte setzen:
|
||||
|
||||
```env
|
||||
NODE_ENV=production
|
||||
PORT=8124
|
||||
VENDOO_BIND_HOST=0.0.0.0
|
||||
VENDOO_DATA_DIR=/app/data
|
||||
VENDOO_DB_PATH=/app/data/db/vendoo.db
|
||||
VENDOO_UPLOADS_DIR=/app/data/uploads
|
||||
VENDOO_BACKUP_DIR=/app/data/backups
|
||||
VENDOO_OPERATIONS_DIR=/app/data/operations
|
||||
VENDOO_LOG_DIR=/app/data/logs
|
||||
VENDOO_CONFIG_PATH=/app/data/config/vendoo.env
|
||||
VENDOO_MODULES_DIR=/app/data/modules
|
||||
VENDOO_MODULE_STATE_PATH=/app/data/config/modules-state.json
|
||||
|
||||
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_REQUIRE_SETUP_TOKEN=true
|
||||
VENDOO_SETUP_TOKEN=<MINDESTENS_64_ZUFAELLIGE_ZEICHEN>
|
||||
|
||||
VENDOO_INITIAL_DISABLED_MODULES=vendoo.flux-studio
|
||||
LOCAL_IMAGE_ENABLED=false
|
||||
LOCAL_IMAGE_ALLOW_REMOTE=false
|
||||
VENDOO_JSON_LOGS=true
|
||||
SMTP_TLS_REJECT_UNAUTHORIZED=true
|
||||
```
|
||||
|
||||
Den Setup-Token nicht aus dieser Dokumentation übernehmen. Einen neuen zufälligen Wert erzeugen und ausschließlich in Coolify speichern.
|
||||
|
||||
## 7. Healthcheck
|
||||
|
||||
Wenn Coolify eigene Healthcheck-Felder anbietet:
|
||||
|
||||
```text
|
||||
Enabled: Ja
|
||||
Method: GET
|
||||
Path: /readyz
|
||||
Port: 8124
|
||||
Interval: 30 Sekunden
|
||||
Timeout: 5 Sekunden
|
||||
Retries: 3
|
||||
Start Period: 30 Sekunden
|
||||
```
|
||||
|
||||
Der Dockerfile enthält denselben Healthcheck bereits.
|
||||
|
||||
## 8. Auto Deploy
|
||||
|
||||
Für kontrollierte Produktionsupdates:
|
||||
|
||||
```text
|
||||
Auto Deploy: deaktiviert
|
||||
Preview Deployments: optional aktiviert
|
||||
```
|
||||
|
||||
Damit führt nicht jeder Merge sofort ein Produktionsdeployment aus. Das erste Deployment wird manuell in Coolify gestartet. Spätere Deployments können aus dem Vendoo Update Center angefordert werden.
|
||||
|
||||
Für einen einfachen Testbetrieb kann Auto Deploy vorübergehend aktiviert werden.
|
||||
|
||||
## 9. Erstes Deployment
|
||||
|
||||
1. In Coolify `Deploy` anklicken.
|
||||
2. Build-Logs beobachten.
|
||||
3. Warten, bis der Container `healthy` meldet.
|
||||
4. `https://vendoo.flatlined.de/readyz` öffnen.
|
||||
5. Danach `https://vendoo.flatlined.de` öffnen.
|
||||
6. Ersteinrichtung mit dem in Coolify gesetzten Setup-Token abschließen.
|
||||
7. Ersten Administrator anlegen.
|
||||
8. Unter `Administration → Module` prüfen, dass FLUX Studio deaktiviert ist.
|
||||
|
||||
`VENDOO_INITIAL_DISABLED_MODULES` gilt nur als erster Standard. Wird FLUX später bewusst im Modulmanager aktiviert, bleibt diese Administratorentscheidung persistent erhalten.
|
||||
|
||||
## 10. Coolify-Deployment im Vendoo Update Center konfigurieren
|
||||
|
||||
### Empfohlen: Deploy-Webhook
|
||||
|
||||
1. In Coolify die Vendoo-Anwendung öffnen.
|
||||
2. Den Bereich für Deploy Webhooks beziehungsweise Webhooks öffnen.
|
||||
3. Einen Deploy-Webhook für diese Anwendung kopieren oder erstellen.
|
||||
4. In Vendoo `Administration → System → Update Center` öffnen.
|
||||
5. Provider `Coolify` wählen.
|
||||
6. Coolify URL eintragen, zum Beispiel `https://coolify.flatlined.de`.
|
||||
7. Trigger `Deploy-Webhook` wählen.
|
||||
8. Den vollständigen Webhook in `Deploy-Webhook` eintragen.
|
||||
9. Repository `Masterluke77/vendoo` eintragen.
|
||||
10. Produktionsbranch `main` eintragen.
|
||||
11. Vorab-Backup aktiviert lassen.
|
||||
12. Konfiguration speichern.
|
||||
13. `Verbindung prüfen` anklicken.
|
||||
|
||||
Der Webhook wird verschlüsselt in `/app/data/config/secrets.enc.json` gespeichert und nicht an den Browser zurückgegeben.
|
||||
|
||||
### Alternative: Coolify API
|
||||
|
||||
1. In Coolify `Settings → Advanced` öffnen und API Access aktivieren.
|
||||
2. Unter `Security → API Tokens` einen Token erstellen.
|
||||
3. Nur die Berechtigungen `read` und `deploy` vergeben.
|
||||
4. Den Token sofort kopieren; Coolify zeigt ihn nur einmal.
|
||||
5. Die Application Resource UUID aus Coolify kopieren.
|
||||
6. In Vendoo Trigger `Coolify API` wählen.
|
||||
7. Coolify URL, Resource UUID und API-Token eintragen.
|
||||
8. Konfiguration speichern.
|
||||
|
||||
Keinen Root-Token verwenden.
|
||||
|
||||
## 11. Deployment aus Vendoo auslösen
|
||||
|
||||
1. Neue Version zuerst in GitHub nach `main` mergen.
|
||||
2. GitHub Actions vollständig grün abwarten.
|
||||
3. Optional GitHub Release veröffentlichen.
|
||||
4. In der laufenden Vendoo-Installation das Update Center öffnen.
|
||||
5. `Coolify-Deployment starten` anklicken.
|
||||
6. Exakt `DEPLOY` eingeben.
|
||||
7. Vendoo erstellt zuerst ein verifiziertes Backup einschließlich Konfiguration.
|
||||
8. Danach wird der Coolify-Auftrag gesendet.
|
||||
9. Coolify baut einen neuen Container aus dem konfigurierten Branch.
|
||||
10. Der laufende Container verändert sich nicht selbst.
|
||||
|
||||
## 12. Nachkontrolle
|
||||
|
||||
Nach jedem Deployment prüfen:
|
||||
|
||||
- `https://vendoo.flatlined.de/readyz`
|
||||
- Anmeldung
|
||||
- Artikel und Medien
|
||||
- Modulmanager
|
||||
- Security Center
|
||||
- Update Center
|
||||
- Backupliste
|
||||
- Coolify Build- und Containerlogs
|
||||
|
||||
## 13. Rollback
|
||||
|
||||
Bei einem fehlerhaften Deployment:
|
||||
|
||||
1. In Coolify die Vendoo-Anwendung öffnen.
|
||||
2. `Deployments` beziehungsweise Deployment History öffnen.
|
||||
3. das letzte funktionierende lokale Image wählen.
|
||||
4. Rollback ausführen.
|
||||
5. `/readyz` prüfen.
|
||||
6. Daten nur dann wiederherstellen, wenn eine Migration oder ein Nutzdatenproblem vorliegt.
|
||||
|
||||
Da Vendoo-Daten im Volume `/app/data` liegen, ersetzt ein Containerrollback normalerweise nur den Programmstand und nicht die Nutzdaten.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Vendoo Full Listing Editor 2026
|
||||
|
||||
## Ziel
|
||||
|
||||
Bereits gespeicherte Artikel werden nicht mehr in einem reduzierten Detailformular, sondern in einem vollständigen Arbeitsbereich bearbeitet. Generator und Listing-Editor verwenden dieselbe Rich-Text- und HTML-Logik.
|
||||
|
||||
## Funktionsumfang
|
||||
|
||||
- vollständige Bearbeitung aller Listing-Felder
|
||||
- Plattform, AI-Provider, Sprache, Status, SKU und Lagerort
|
||||
- Titel, Tags, Verkäufernotizen und sämtliche erkannten Attribute
|
||||
- Preis und Kategorie
|
||||
- Foto hinzufügen, entfernen, sortieren und als Cover festlegen
|
||||
- vorhandene Fotos mit Helligkeit, Kontrast, Sättigung, Rotation, Spiegelung und Crop bearbeiten
|
||||
- WYSIWYG und HTML-Code gleichzeitig sichtbar
|
||||
- Änderungen im WYSIWYG erscheinen sofort im HTML-Code
|
||||
- Änderungen im HTML-Code werden in den WYSIWYG-Editor zurückgeführt
|
||||
- separate sandboxed Plattformvorschau
|
||||
- Editor-HTML und Plattform-HTML separat kopierbar
|
||||
|
||||
## Datenmodell
|
||||
|
||||
`listings.description_html` speichert das bereinigte Rich-Text-HTML. `listings.description` bleibt als Klartext-Fallback und für Plattformen beziehungsweise Exporte erhalten.
|
||||
|
||||
Die neue Spalte wird über das bestehende `MIGRATIONS`-Array in `lib/db.mjs` ergänzt.
|
||||
|
||||
## Sicherheit
|
||||
|
||||
HTML wird auf unterstützte Formatierungs-Tags reduziert. Skripte, eingebettete Frames, Formulare, Event-Handler und gefährliche URLs werden entfernt. Vorschauen werden in einem `sandbox`-iframe dargestellt.
|
||||
@@ -0,0 +1,61 @@
|
||||
# Vendoo Listing Studio 2026
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Listing-Generator ist kein Formularstapel mehr, sondern ein zusammenhängender Studio-Arbeitsplatz mit drei klaren Zonen:
|
||||
|
||||
1. Fotos & Medien
|
||||
2. AI-Konfiguration
|
||||
3. Vorschau & Bearbeitung
|
||||
|
||||
Die bestehende Vanilla-JS-, Express- und SQLite-Architektur bleibt erhalten.
|
||||
|
||||
## Fotos & Medien
|
||||
|
||||
- großes Cover mit vollständiger Bilddarstellung über `object-fit: contain`
|
||||
- Klick auf ein Vorschaubild setzt es als Cover
|
||||
- Drag & Drop sortiert die Bildreihenfolge
|
||||
- maximal zehn Bilder pro Listing
|
||||
- sichtbarer Foto-Check mit Qualitätsindikatoren
|
||||
- bestehender Bildeditor, Hintergrundentfernung und Wasserzeichen bleiben integriert
|
||||
|
||||
## AI-Konfiguration
|
||||
|
||||
- Plattform, Provider und Modell
|
||||
- Sprache und Anzahl der Varianten
|
||||
- Vorlagenauswahl
|
||||
- Verkäufernotizen mit Zeichenzähler
|
||||
- Vorlagen übernehmen Plattform, Sprache, Hinweise und Standard-Tags
|
||||
- global hinterlegte Verkäuferhinweise, Vorlagenhinweise und Artikelhinweise werden kontrolliert zusammengeführt
|
||||
|
||||
## Vorschau & Bearbeitung
|
||||
|
||||
- permanenter, kontextbezogener Ergebnisbereich
|
||||
- Live-Zähler für Titel, Beschreibung und Tags
|
||||
- editierbare erkannte Attribute
|
||||
- Kategorie-Picker, Preis und Lagerort
|
||||
- dynamische Gebührenvorschau
|
||||
- nachvollziehbarer Qualitätswert
|
||||
- HTML- und Plattformvorschau als optional aufklappbarer Bereich
|
||||
- Speichern und Kopieren ohne Fensterwechsel
|
||||
|
||||
## API-Erweiterung
|
||||
|
||||
`POST /api/generate` akzeptiert zusätzlich:
|
||||
|
||||
```json
|
||||
{
|
||||
"template_id": 1,
|
||||
"seller_notes": "Artikelspezifische Hinweise"
|
||||
}
|
||||
```
|
||||
|
||||
Standard-Tags der gewählten Vorlage werden dedupliziert mit den AI-Tags zusammengeführt.
|
||||
|
||||
## Qualitätsregeln
|
||||
|
||||
- keine neuen Frameworks
|
||||
- keine neuen Datenbankspalten
|
||||
- bestehende IDs und Generatorfunktionen bleiben kompatibel
|
||||
- alle Farben und Zustände nutzen die Vendoo-CSS-Variablen
|
||||
- Dark Mode und responsive Darstellung sind Bestandteil des Slices
|
||||
@@ -0,0 +1,76 @@
|
||||
# Vendoo 1.34.0 – GitHub Deployment
|
||||
|
||||
## Repository
|
||||
|
||||
- Repository: `Masterluke77/vendoo`
|
||||
- Sichtbarkeit: privat
|
||||
- Stabiler Branch: `main`
|
||||
- Entwicklungsbranch: `develop`
|
||||
- Erstimport-Branch: `release/1.34.0-initial-import`
|
||||
|
||||
## Kontrollierter Erstimport
|
||||
|
||||
Unter Windows wird `GitHub-Deploy-Assistent.bat` gestartet. Der Assistent:
|
||||
|
||||
1. prüft beziehungsweise installiert Git für Windows über `winget`,
|
||||
2. klont die vorhandene GitHub-Baseline in einen temporären Arbeitsordner,
|
||||
3. verwendet oder erstellt `release/1.34.0-initial-import`,
|
||||
4. kopiert nur den bereinigten Vendoo-Quellstand,
|
||||
5. blockiert `.env`, Datenbanken, Uploads, Backups, Logs, Laufzeitdaten und Modelle,
|
||||
6. führt nach Möglichkeit `tools/verify-git-safety.mjs` aus,
|
||||
7. zeigt alle Änderungen vor dem Commit,
|
||||
8. verlangt zur Freigabe die exakte Eingabe `PUSH`,
|
||||
9. pusht ausschließlich den Release-Branch,
|
||||
10. öffnet den vorbereiteten Pull-Request-Vergleich im Browser.
|
||||
|
||||
Der Assistent löscht oder verändert keine produktiven Vendoo-Daten. Der temporäre Git-Arbeitsordner wird nach Abschluss entfernt.
|
||||
|
||||
## Pull Request und Merge
|
||||
|
||||
Der Pull Request wird gegen `main` erstellt. Vor dem Merge müssen die GitHub-Actions-Prüfungen erfolgreich sein:
|
||||
|
||||
- reproduzierbare Installation über `npm ci`,
|
||||
- Git-Sicherheitsgate,
|
||||
- JavaScript-/MJS-Syntax,
|
||||
- Deployment-Gate 1.34.0,
|
||||
- Datenbankmigrationstest,
|
||||
- Compose-Prüfung für lokal, NAS und VPS,
|
||||
- Docker-Testbuild.
|
||||
|
||||
Empfohlen ist ein Squash-Merge. Erst danach wird ein GitHub Release `v1.34.0` veröffentlicht.
|
||||
|
||||
## Release-Automation
|
||||
|
||||
Beim Veröffentlichen eines GitHub Releases:
|
||||
|
||||
- wird ein bereinigtes Release-Staging erzeugt,
|
||||
- werden Einzeldatei-SHA-256-Prüfsummen erzeugt,
|
||||
- wird `Vendoo_1.34.0.zip` gebaut,
|
||||
- wird eine SHA-256-Datei für das ZIP erzeugt,
|
||||
- werden beide Dateien an das GitHub Release angehängt,
|
||||
- wird ein Multi-Arch-Container für `linux/amd64` und `linux/arm64` gebaut,
|
||||
- wird das Image als `ghcr.io/masterluke77/vendoo` in die GitHub Container Registry veröffentlicht,
|
||||
- wird der veröffentlichte Image-Digest mit einer GitHub-Provenienz-Attestierung versehen.
|
||||
|
||||
Das Release-ZIP wird nicht dauerhaft in die Git-Historie committed.
|
||||
|
||||
## Secrets
|
||||
|
||||
Produktive Secrets gehören ausschließlich in:
|
||||
|
||||
- die lokale `.env`, die der Installer automatisch erzeugt,
|
||||
- den persistenten Runtime-Konfigurationsspeicher von Vendoo,
|
||||
- gegebenenfalls geschützte GitHub Environments für spätere Deployments.
|
||||
|
||||
Nicht zulässig sind Secrets in Quellcode, Issues, Pull Requests, Workflow-Ausgaben oder Release-Paketen.
|
||||
|
||||
## Späteres Produktionsdeployment
|
||||
|
||||
Ein automatisches Deployment auf NAS oder VPS wird erst freigeschaltet, wenn diese Gates praktisch bestätigt sind:
|
||||
|
||||
- Backup und Restore auf dem Zielsystem,
|
||||
- Readiness nach Update,
|
||||
- Rollback auf die vorherige Container-Version,
|
||||
- TLS und Domainprüfung,
|
||||
- getrennte Staging- und Produktionsumgebung,
|
||||
- manuelle Freigabe des GitHub Environments `production`.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Vendoo GitHub-Importstatus
|
||||
|
||||
- Zielrelease: `1.36.0`
|
||||
- Importbranch: `release/1.36.0-theme-manager`
|
||||
- Zielbranch: `main`
|
||||
- Draft Pull Request: `#9`
|
||||
|
||||
Der vollständige Quellstand wird über `GitHub-Deploy-Assistent.bat` beziehungsweise `scripts/github-deploy.sh` übertragen. Vor dem Merge müssen Git-Sicherheitsgate, Theme-Manager-Gate, Architektur-Gate, Datenbankmigrationen und GitHub Actions erfolgreich sein.
|
||||
|
||||
Nicht nach GitHub gelangen dürfen `.env`, Datenbanken, Uploads, Backups, Logs, Operations-/Update-Artefakte oder FLUX-/ComfyUI-Modelle.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Vendoo 1.39.0 – GitHub-Importstatus
|
||||
|
||||
- Repository: `Masterluke77/vendoo`
|
||||
- Importbranch: `release/1.39.0-catalog-media`
|
||||
- Zielbranch: `main`
|
||||
- Draft Pull Request: `#12`
|
||||
|
||||
Der vollständige Quellstand wird über `GitHub-Deploy-Assistent.bat` beziehungsweise `scripts/github-deploy.sh` übertragen. Der Assistent erstellt ein bereinigtes Staging, prüft Secrets und Laufzeitdaten und pusht erst nach der exakten Bestätigung `PUSH`.
|
||||
|
||||
Pull Request #12 darf erst nach geprüftem Diff und vollständig erfolgreicher GitHub CI zusammengeführt werden.
|
||||
@@ -0,0 +1,10 @@
|
||||
# Vendoo 1.41.0 – GitHub-Importstatus
|
||||
|
||||
- Importbranch: `release/1.41.0-coolify-production`
|
||||
- Zielbranch: `main`
|
||||
- Pull Request: `#16`
|
||||
- Status: vorbereitet
|
||||
|
||||
Der Branch und der Draft Pull Request sind angelegt. Auf GitHub befindet sich zunächst nur die Markierungsdatei. Der vollständige Quellstand wird nach der lokalen Installation ausschließlich über `GitHub-Deploy-Assistent.bat` aus `W:\ChatGPT\Vendoo` übertragen.
|
||||
|
||||
Vor dem Merge müssen der vollständige Diff, sämtliche GitHub-Actions-Checks, die Docker-Prüfung und die Release-Verträge erfolgreich sein.
|
||||
@@ -0,0 +1,8 @@
|
||||
# Vendoo 1.41.1 – GitHub-Importstatus
|
||||
|
||||
- Importbranch: `release/1.41.1-ci-source-root-hotfix`
|
||||
- Zielbranch: `main`
|
||||
- Pull Request: `#17`
|
||||
- Status: vorbereitet
|
||||
|
||||
Der vollständige Quellstand wird ausschließlich über `GitHub-Deploy-Assistent.bat` übertragen. Das Staging entfernt dabei historische Ordner `Archiv/`, `archive/` und `archives/` einschließlich bereits im Zielbranch vorhandener Dateien.
|
||||
@@ -0,0 +1,7 @@
|
||||
# Vendoo 1.41.2 – GitHub-Importstatus
|
||||
|
||||
- Importbranch: `release/1.41.2-git-ignore-boundary-hotfix`
|
||||
- Zielbranch: `main`
|
||||
- Status: vorbereitet
|
||||
|
||||
Der vollständige Quellstand wird über `GitHub-Deploy-Assistent.bat` übertragen. Der Assistent prüft nach `git add --all`, dass alle produktiven Dateien unter `app/modules/` tatsächlich von Git getrackt werden.
|
||||
@@ -0,0 +1,175 @@
|
||||
# Vendoo 1.41.0 – GitHub Push, Pull Request, Merge und Release
|
||||
|
||||
## Grundregel
|
||||
|
||||
Der Produktionsbranch ist `main`. Direkt auf `main` wird nicht entwickelt. Jeder neue Vendoo-Stand wird zuerst auf einen Release- oder Hotfix-Branch übertragen, durch GitHub Actions geprüft und anschließend per Pull Request gemergt.
|
||||
|
||||
## Teil A – vollständigen Quellstand hochladen
|
||||
|
||||
Auf dem Windows-Rechner nach erfolgreichem lokalen Start von 1.41.0:
|
||||
|
||||
1. `W:\ChatGPT\Vendoo\GitHub-Deploy-Assistent.bat` starten.
|
||||
2. Der Assistent bereitet ein sauberes Git-Staging vor.
|
||||
3. Den vollständigen Sicherheitsbericht lesen.
|
||||
4. Prüfen, dass keine dieser Dateien im Git-Status erscheint:
|
||||
- `.env`
|
||||
- Datenbanken
|
||||
- Uploads
|
||||
- Backups
|
||||
- Logs
|
||||
- `master.key`
|
||||
- `secrets.enc.json`
|
||||
- `modules/`
|
||||
- `updates/`
|
||||
5. Prüfen, dass der Zielbranch lautet:
|
||||
|
||||
```text
|
||||
release/1.41.0-coolify-production
|
||||
```
|
||||
|
||||
6. Erst danach exakt eingeben:
|
||||
|
||||
```text
|
||||
PUSH
|
||||
```
|
||||
|
||||
7. Den Assistenten vollständig abschließen lassen.
|
||||
|
||||
## Teil B – Pull Request #16 prüfen
|
||||
|
||||
1. GitHub öffnen.
|
||||
2. Repository `Masterluke77/vendoo` öffnen.
|
||||
3. `Pull requests` öffnen.
|
||||
4. PR `Vendoo 1.41.0 – Coolify Production Deployment & Controlled Web Updates` öffnen.
|
||||
5. Prüfen:
|
||||
|
||||
```text
|
||||
Base: main
|
||||
Compare: release/1.41.0-coolify-production
|
||||
```
|
||||
|
||||
6. Unter `Files changed` kontrollieren, dass der vollständige Quellstand enthalten ist.
|
||||
7. Besonders prüfen:
|
||||
- `Dockerfile`
|
||||
- `deploy/coolify.env.example`
|
||||
- `.github/workflows/ci.yml`
|
||||
- `.github/workflows/release.yml`
|
||||
- `app/modules/deployments/`
|
||||
- `app/kernel/platform-kernel.mjs`
|
||||
- `public/index.html`
|
||||
- `public/app.js`
|
||||
- `docs/COOLIFY_PRODUCTION_1_41_0.md`
|
||||
8. Unter `Checks` beziehungsweise unten im PR warten, bis alle GitHub-Actions-Prüfungen grün sind.
|
||||
9. Bei einem roten Check nicht mergen. Den fehlgeschlagenen Job öffnen und den vollständigen Fehler korrigieren.
|
||||
|
||||
## Teil C – Draft beenden
|
||||
|
||||
Der vorbereitete PR ist zunächst ein Draft.
|
||||
|
||||
1. Im PR `Ready for review` anklicken.
|
||||
2. Erneut prüfen, dass alle Checks grün sind.
|
||||
3. Keine offenen Review-Kommentare stehen lassen.
|
||||
|
||||
## Teil D – Merge
|
||||
|
||||
Empfohlen:
|
||||
|
||||
```text
|
||||
Squash and merge
|
||||
```
|
||||
|
||||
Vorgehen:
|
||||
|
||||
1. Pfeil neben dem Merge-Button öffnen.
|
||||
2. `Squash and merge` auswählen.
|
||||
3. Commit-Titel verwenden:
|
||||
|
||||
```text
|
||||
Vendoo 1.41.0 – Coolify Production Deployment & Controlled Web Updates
|
||||
```
|
||||
|
||||
4. Merge bestätigen.
|
||||
5. Prüfen, dass der PR den Status `Merged` hat.
|
||||
6. Den Release-Branch anschließend über `Delete branch` löschen.
|
||||
|
||||
Nicht den lokalen Vendoo-Ordner löschen. Nur der GitHub-Release-Branch darf nach dem Merge entfernt werden.
|
||||
|
||||
## Teil E – main prüfen
|
||||
|
||||
1. Repository-Startseite öffnen.
|
||||
2. Branch `main` auswählen.
|
||||
3. Prüfen, dass `package.json` Version `1.41.0` enthält.
|
||||
4. `Actions` öffnen.
|
||||
5. Den letzten Workflow auf `main` prüfen.
|
||||
6. Erst fortfahren, wenn `Vendoo CI` erfolgreich ist.
|
||||
|
||||
## Teil F – GitHub Release veröffentlichen
|
||||
|
||||
1. Rechts im Repository `Releases` öffnen.
|
||||
2. `Draft a new release` anklicken.
|
||||
3. `Choose a tag` wählen.
|
||||
4. Neuen Tag erstellen:
|
||||
|
||||
```text
|
||||
v1.41.0
|
||||
```
|
||||
|
||||
5. Target Branch `main` wählen.
|
||||
6. Release title:
|
||||
|
||||
```text
|
||||
Vendoo 1.41.0 – Coolify Production Deployment & Controlled Web Updates
|
||||
```
|
||||
|
||||
7. Release Notes aus `CHANGELOG.md` übernehmen.
|
||||
8. `Set as the latest release` aktivieren.
|
||||
9. Nicht als Pre-Release markieren.
|
||||
10. `Publish release` anklicken.
|
||||
|
||||
Danach startet der Workflow `Vendoo Release`.
|
||||
|
||||
## Teil G – Release-Workflow kontrollieren
|
||||
|
||||
Unter `Actions → Vendoo Release` müssen beide Jobs erfolgreich sein:
|
||||
|
||||
1. `Release-Paket und Prüfsummen`
|
||||
2. `GHCR-Container veröffentlichen`
|
||||
|
||||
Der Workflow erzeugt:
|
||||
|
||||
- Release-ZIP
|
||||
- SHA-256-Datei
|
||||
- `ghcr.io/masterluke77/vendoo:1.41.0`
|
||||
- `ghcr.io/masterluke77/vendoo:1.41`
|
||||
- `ghcr.io/masterluke77/vendoo:stable`
|
||||
- `ghcr.io/masterluke77/vendoo:latest`
|
||||
- SBOM und Provenienz/Attestation
|
||||
|
||||
## Teil H – erstes Coolify-Deployment
|
||||
|
||||
Für die erste Installation:
|
||||
|
||||
1. Coolify-Anwendung mit GitHub-Repository und Branch `main` verbinden.
|
||||
2. Auto Deploy zunächst deaktivieren.
|
||||
3. `Deploy` manuell anklicken.
|
||||
4. Build-Logs und Healthcheck prüfen.
|
||||
5. `https://vendoo.flatlined.de/readyz` öffnen.
|
||||
6. Ersteinrichtung durchführen.
|
||||
7. Coolify-Webhook im Vendoo Update Center speichern.
|
||||
|
||||
## Teil I – zukünftiger Updateablauf
|
||||
|
||||
Für spätere Releases immer in dieser Reihenfolge:
|
||||
|
||||
1. neue Version lokal entwickeln und testen
|
||||
2. Release-Branch pushen
|
||||
3. Pull Request öffnen
|
||||
4. GitHub Actions grün
|
||||
5. PR nach `main` mergen
|
||||
6. GitHub Release veröffentlichen
|
||||
7. laufendes Vendoo öffnen
|
||||
8. Update Center öffnen
|
||||
9. Coolify-Deployment mit `DEPLOY` bestätigen
|
||||
10. `/readyz` und Anwendung prüfen
|
||||
|
||||
Mit deaktiviertem Coolify Auto Deploy bleibt der Produktionsstand aktiv, bis der Administrator den Deployment-Auftrag bewusst aus Vendoo oder Coolify auslöst.
|
||||
@@ -0,0 +1,20 @@
|
||||
# Vendoo 1.23.1 – Editor-/Vinted-Hotfix
|
||||
|
||||
## Behobene Fehler
|
||||
|
||||
1. Der Advanced Image Editor war nur über ein kleines Stift-Symbol erreichbar und konnte bei alten Browser-Assets scheinbar vollständig fehlen.
|
||||
2. Die Vinted-Auswahl für Zustand, Marke, Größe oder Farbe konnte durch einen zu breiten DOM-Fallback das Titelfeld als erstes Eingabefeld auswählen und überschreiben.
|
||||
|
||||
## Umsetzung
|
||||
|
||||
- Sichtbarer Button **Advanced Editor öffnen** im Generator.
|
||||
- Versionsparameter für `app.js` und `style.css`.
|
||||
- `Cache-Control: no-store` für HTML, JavaScript und CSS.
|
||||
- Build-Kennung 1.23.1 im HTML und beim Browserstart.
|
||||
- Strikte, labelgebundene Feldauflösung in allen Chrome-, Edge- und Firefox-Paketen.
|
||||
- Zusätzlicher Titelfeldschutz für Choice-Felder.
|
||||
- Extension-Version 1.6.1.
|
||||
|
||||
## Nutzeraktion nach Installation
|
||||
|
||||
Die Browser-Erweiterung muss in der Erweiterungsverwaltung einmal über **Neu laden** aktualisiert werden. Danach die Vinted-Verkaufsseite vollständig neu laden.
|
||||
@@ -0,0 +1,23 @@
|
||||
# Vendoo 1.23.2 – FLUX-/Editor-Hotfix
|
||||
|
||||
## FLUX Studio
|
||||
|
||||
- `System & ComfyUI` befindet sich unterhalb von `Prompt & Auftrag`.
|
||||
- Die angeheftete Bildvorschau enthält keine darunterliegende Systemkarte mehr und kann dadurch die Bildaktionen nicht überdecken.
|
||||
- Das komplette Job-Center kann ein- oder ausgeklappt werden.
|
||||
- Jeder Auftrag besitzt eine kompakte Kopfzeile und einen einzeln ein-/ausklappbaren Detailbereich.
|
||||
- Aktive Aufträge werden beim ersten Laden geöffnet; terminale Aufträge bleiben kompakt.
|
||||
|
||||
## Advanced Image Editor
|
||||
|
||||
- Hintergrundentfernung ist als Editor-Operation integriert.
|
||||
- Wasserzeichen unterstützt Text, Deckkraft sowie oben/unten links/rechts und Mitte.
|
||||
- Beide Werkzeuge werden nicht destruktiv als neue Version gespeichert.
|
||||
- Die bisherigen separaten Buttons wurden entfernt.
|
||||
- Die Werkzeuge funktionieren in Generator, Listing-Editor und FLUX Studio.
|
||||
|
||||
## Unveränderte Schutzregeln
|
||||
|
||||
- Kein VTO/FASHN.
|
||||
- Keine produktiven Daten oder Modelle im Paket.
|
||||
- Vendoo Link bleibt 1.6.1; der Vinted-Feldschutz wird nicht zurückgenommen.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Hotfix – Studio Flow Detailnavigation
|
||||
|
||||
## Fehler
|
||||
|
||||
Der Button **Prüfen & bearbeiten** lud die Listing-Detailansicht, ohne zuvor den Listings-Tab sichtbar zu schalten. Der Editor wurde dadurch in einem ausgeblendeten Bereich aufgebaut.
|
||||
|
||||
## Korrektur
|
||||
|
||||
`showDetail(id)` prüft nun zentral, ob der Listings-/Historie-Tab aktiv ist. Falls nicht, wird dieser vor dem Laden des Listings aktiviert. Damit funktionieren Detailaufrufe aus:
|
||||
|
||||
- Studio Flow
|
||||
- Attention Queue
|
||||
- Listings-Tabelle
|
||||
- weiteren internen Bereichen
|
||||
|
||||
Zusätzlich werden ungültige Listing-IDs abgefangen.
|
||||
@@ -0,0 +1,134 @@
|
||||
# Vendoo 1.32.0 – Installation, Update und Prüfung
|
||||
|
||||
## A. Windows-Update von 1.31.0
|
||||
|
||||
1. Vendoo sowie offene Setup-, Node- und FLUX-Fenster schließen.
|
||||
2. Das Release-ZIP vollständig in einen temporären Ordner entpacken.
|
||||
3. Im entpackten Paket den Ordner `vendoo` öffnen.
|
||||
4. Den **Inhalt** dieses Ordners nach `W:\ChatGPT\Vendoo` kopieren.
|
||||
5. Windows-Abfrage **Dateien im Ziel ersetzen** bestätigen.
|
||||
6. `W:\ChatGPT\Vendoo` vorher **nicht löschen, leeren oder umbenennen**.
|
||||
7. `.env`, `db\vendoo.db`, `uploads`, `backups`, `operations`, lokale FLUX-Modelle und ComfyUI-Daten nicht löschen.
|
||||
8. `W:\ChatGPT\Vendoo\setup.bat` starten.
|
||||
9. Menüpunkt **3 – Update** ausführen.
|
||||
10. Danach Menüpunkt **2 – Starten** ausführen.
|
||||
11. `http://127.0.0.1:8124/healthz` und `http://127.0.0.1:8124/readyz` prüfen.
|
||||
|
||||
Windows benötigt die neuen Pfadvariablen nicht. Ohne Eintrag bleiben DB, Uploads und Backups exakt an ihren bisherigen Orten.
|
||||
|
||||
## B. Docker-Neuinstallation
|
||||
|
||||
1. Release entpacken und in den gewünschten Server-/NAS-Ordner wechseln.
|
||||
2. `.env.example` als `.env` kopieren.
|
||||
3. Einen starken Einrichtungs-Code erzeugen, mindestens 32 zufällige Zeichen, und als `VENDOO_SETUP_TOKEN` setzen. Beispiele:
|
||||
|
||||
```bash
|
||||
openssl rand -hex 32
|
||||
```
|
||||
|
||||
PowerShell:
|
||||
|
||||
```powershell
|
||||
[Convert]::ToHexString([Security.Cryptography.RandomNumberGenerator]::GetBytes(32)).ToLower()
|
||||
```
|
||||
|
||||
Die `.env` anschließend nur für den Administrator lesbar machen (`chmod 600 .env` auf Linux/NAS).
|
||||
4. Für lokalen Test `PUBLIC_BASE_URL` zunächst leer lassen. Für Produktion die echte HTTPS-URL und Host-/Origin-Allowlist setzen.
|
||||
5. Starten:
|
||||
|
||||
```bash
|
||||
docker compose config
|
||||
docker compose build --pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
6. Zustand prüfen:
|
||||
|
||||
```bash
|
||||
docker compose ps
|
||||
docker compose logs --tail=200 vendoo
|
||||
```
|
||||
|
||||
7. Lokal `http://127.0.0.1:8124/readyz` öffnen. Erwartet wird HTTP 200 und `"ok": true`.
|
||||
8. Vendoo öffnen, ersten Administrator anlegen und dabei den `VENDOO_SETUP_TOKEN` als Einrichtungs-Code eingeben.
|
||||
9. Danach Reverse Proxy und HTTPS konfigurieren. Port 8124 nicht direkt aus dem Internet veröffentlichen.
|
||||
10. Testbackup erstellen und Prüfsumme kontrollieren.
|
||||
|
||||
## C. Portainer/NAS
|
||||
|
||||
### Empfohlen: Named Volumes
|
||||
|
||||
`compose.yaml` direkt als Stack verwenden. Portainer legt fünf persistente Volumes an. Das Image läuft ohne Rootrechte.
|
||||
|
||||
### Option: sichtbare NAS-Ordner
|
||||
|
||||
1. Einen dedizierten Zielordner verwenden, zum Beispiel `/volume1/docker/vendoo`, und darunter anlegen:
|
||||
|
||||
```text
|
||||
runtime/db
|
||||
runtime/uploads
|
||||
runtime/backups
|
||||
runtime/operations
|
||||
runtime/logs
|
||||
```
|
||||
|
||||
2. Diese Ordner UID/GID 1000 schreibbar machen. Den Vendoo-Container nicht als Root starten.
|
||||
3. Compose mit Override starten:
|
||||
|
||||
```bash
|
||||
docker compose -f compose.yaml -f compose.bind-mounts.example.yaml up -d --build
|
||||
```
|
||||
|
||||
Bei `Kein Schreibzugriff ... (Container-UID 1000)` keine Root-Ausführung aktivieren, sondern die Ordnerrechte korrigieren. `LOCAL_IMAGE_ENABLED` bleibt im Hauptcontainer standardmäßig `false`; ein vorhandenes FLUX/ComfyUI wird separat betrieben und über `LOCAL_IMAGE_URL` angebunden.
|
||||
|
||||
## D. Docker-Update
|
||||
|
||||
```bash
|
||||
./scripts/docker-backup.sh
|
||||
# neuen Vendoo-Code über den alten Codeordner kopieren; .env nicht ersetzen
|
||||
docker compose config
|
||||
docker compose build --pull
|
||||
docker compose up -d --force-recreate
|
||||
docker compose ps
|
||||
docker compose logs --tail=200 vendoo
|
||||
```
|
||||
|
||||
Anschließend `/readyz`, Login, Artikelübersicht, ein vorhandenes Bild, Speichern eines Testartikels, SmartCopy und Publish-Center ohne echte Veröffentlichung prüfen.
|
||||
|
||||
### Rollback
|
||||
|
||||
1. Container stoppen.
|
||||
2. Vorheriges Image beziehungsweise vorherigen Code wieder verwenden.
|
||||
3. Volumes nicht löschen.
|
||||
4. Container starten und Readiness prüfen.
|
||||
5. Nur wenn eine Datenmigration das verlangt, das zuvor erzeugte gemeinsame DB-/Upload-Backup in einen sicheren Testpfad zurückspielen und erst danach produktiv restaurieren.
|
||||
|
||||
## E. Backup und Restore
|
||||
|
||||
Backup mit kurzem geordnetem Stopp:
|
||||
|
||||
```bash
|
||||
./scripts/docker-backup.sh
|
||||
```
|
||||
|
||||
Restore ersetzt die aktuell gemounteten DB-, Upload-, Backup-, Operations- und Logdaten. Das Skript prüft eine vorhandene SHA-256-Datei und erstellt vorab automatisch ein zusätzliches Sicherheitsbackup:
|
||||
|
||||
```bash
|
||||
./scripts/docker-restore.sh /pfad/zum/vendoo-data.tar.gz --confirm
|
||||
```
|
||||
|
||||
Danach zwingend `/readyz`, Login, Benutzer, Artikel, Bilder und Backup-Liste prüfen.
|
||||
|
||||
## F. Funktionsprüfung
|
||||
|
||||
- Login, Logout und erneute Anmeldung
|
||||
- Rollen-/Adminschutz
|
||||
- Artikel laden, erstellen, bearbeiten und speichern
|
||||
- Bild hochladen und erneut abrufen
|
||||
- Galerie-Viewer und Zoom
|
||||
- SmartCopy öffnen und Inhalte kopieren
|
||||
- Publish-Center laden, ohne echte Veröffentlichung auszulösen
|
||||
- `/healthz` und `/readyz`
|
||||
- Containerneustart; Artikel und Bilder müssen erhalten bleiben
|
||||
- Backup erzeugen und SHA-256 prüfen
|
||||
- FLUX-Ausfall: Vendoo muss weiter starten und Kernfunktionen bereitstellen
|
||||
@@ -0,0 +1,105 @@
|
||||
# Vendoo 1.33.0 – Installation und Abnahme
|
||||
|
||||
## 1. Bestehende Windows-Installation aktualisieren
|
||||
|
||||
1. Vendoo und FLUX schließen.
|
||||
2. Release entpacken.
|
||||
3. Den Inhalt von `vendoo` über den vorhandenen Projektordner kopieren.
|
||||
4. Vorhandene Dateien ersetzen, den Zielordner nicht vorher leeren.
|
||||
5. `.env`, Datenbank, Uploads, Backups, Operations, lokale Modelle und ComfyUI-Daten nicht löschen.
|
||||
6. `setup.bat` starten.
|
||||
7. **3 – Update** ausführen.
|
||||
8. **2 – Starten** ausführen.
|
||||
|
||||
## 2. Neue Windows-Installation
|
||||
|
||||
`setup.bat` starten und unter **1 – Installieren / Installationsziel wählen** auswählen:
|
||||
|
||||
- **Windows lokal:** Node.js, npm und lokale Projektordner
|
||||
- **Docker Desktop:** Compose-Build, getrennte Volumes und automatischer Setup-Code
|
||||
- **NAS/Portainer:** Übergabe an den Linux-/NAS-Assistenten
|
||||
- **VPS/Linux:** Installation direkt auf dem Zielserver
|
||||
|
||||
Der gewählte aktive Modus wird in `.vendoo-install-mode` gespeichert. Diese Datei enthält keine Geheimnisse.
|
||||
|
||||
## 3. Linux, NAS oder VPS
|
||||
|
||||
```bash
|
||||
chmod +x setup.sh
|
||||
./setup.sh
|
||||
```
|
||||
|
||||
Auswahl:
|
||||
|
||||
1. Docker auf diesem Linux-/Docker-Host mit Named Volumes
|
||||
2. NAS/Portainer mit sichtbaren `runtime`-Bind-Mounts
|
||||
3. VPS hinter HTTPS-Reverse-Proxy
|
||||
|
||||
Der Assistent prüft Docker und das Compose-Plugin, erzeugt bei Bedarf `.env` sowie einen starken `VENDOO_SETUP_TOKEN`, validiert Compose und startet Vendoo.
|
||||
|
||||
### NAS
|
||||
|
||||
Der NAS-Modus legt folgende Ordner an:
|
||||
|
||||
```text
|
||||
runtime/db
|
||||
runtime/uploads
|
||||
runtime/backups
|
||||
runtime/operations
|
||||
runtime/logs
|
||||
```
|
||||
|
||||
Port 8124 wird im LAN veröffentlicht. Keine direkte Internet-Portfreigabe verwenden.
|
||||
|
||||
### VPS
|
||||
|
||||
- echte öffentliche `https://`-URL angeben
|
||||
- DNS und TLS vorab oder anschließend korrekt konfigurieren
|
||||
- Reverse Proxy auf `127.0.0.1:8124` weiterleiten
|
||||
- Port 8124 nicht öffentlich freigeben
|
||||
- `VENDOO_TRUST_PROXY=true` nur hinter dem eigenen Proxy verwenden
|
||||
|
||||
## 4. FLUX im Docker-Betrieb
|
||||
|
||||
FLUX bleibt ein getrennter Dienst. Im Docker-Container wird ein Host-Dienst über folgende URL erreicht:
|
||||
|
||||
```env
|
||||
LOCAL_IMAGE_URL=http://host.docker.internal:8188
|
||||
```
|
||||
|
||||
`LOCAL_IMAGE_ENABLED` nur aktivieren, wenn FLUX/ComfyUI tatsächlich separat läuft und abgesichert ist.
|
||||
|
||||
## 5. Abnahme
|
||||
|
||||
### Deployment
|
||||
|
||||
- `/healthz` liefert HTTP 200
|
||||
- `/readyz` liefert HTTP 200 und `ok: true`
|
||||
- Neustart erhält Benutzer, Artikel und Bilder
|
||||
- Backup wird erzeugt und hat SHA-256
|
||||
- Docker-Status zeigt `healthy`
|
||||
|
||||
### FLUX Studio
|
||||
|
||||
- Seite öffnen: Vorschau **Auswahl & Varianten** bleibt leer
|
||||
- Historie ist sichtbar, aber kein Bild ist automatisch markiert
|
||||
- Historienbild anklicken: Vorschau erscheint
|
||||
- **Arbeitsbereich zurücksetzen**: Auswahl und Formular werden geleert/zurückgesetzt
|
||||
- Bilder, Verlauf und Job-Center bleiben erhalten
|
||||
|
||||
### Benutzerverwaltung
|
||||
|
||||
- Benutzerliste laden
|
||||
- Bearbeiten-Button öffnet das richtige Benutzerkonto
|
||||
- Name, Rolle und Status speichern
|
||||
- ungültiges Passwort verhindert die gesamte Speicherung
|
||||
- gültiges Passwort wird gesetzt
|
||||
- letzter aktiver Administrator kann nicht deaktiviert oder herabgestuft werden
|
||||
|
||||
## 6. Rollback
|
||||
|
||||
1. Vorheriges Vendoo-Paket über den Code kopieren.
|
||||
2. `.env`, DB, Uploads und Volumes nicht ersetzen oder löschen.
|
||||
3. Windows: `setup.bat` → Update → Starten.
|
||||
4. Docker: `./setup.sh` → Aktualisieren oder vorheriges Image/Code bauen.
|
||||
5. Readiness und Datenbestand prüfen.
|
||||
@@ -0,0 +1,112 @@
|
||||
# Vendoo 1.34.0 – Zero-Edit-Installation
|
||||
|
||||
## Grundsatz
|
||||
|
||||
Für keine unterstützte Betriebsart muss eine `.env`, Compose-Datei oder Proxy-Konfiguration manuell bearbeitet werden. Der Installer sammelt nur notwendige Angaben, validiert sie und schreibt die Konfiguration automatisch.
|
||||
|
||||
AI-, SMTP- und Marktplatz-Zugangsdaten werden nach dem ersten Login unter **Vendoo → Einstellungen** gepflegt. Im Docker-/NAS-/VPS-Betrieb werden diese Werte in einem persistenten Konfigurationsvolume gespeichert und nach Neustarts wieder geladen.
|
||||
|
||||
## Windows lokal
|
||||
|
||||
1. `setup.bat` doppelklicken.
|
||||
2. **Lokal auf diesem Windows-PC** wählen.
|
||||
3. Erreichbarkeit festlegen:
|
||||
- nur dieser PC,
|
||||
- privates LAN.
|
||||
4. Port bestätigen oder ändern.
|
||||
5. optional eine LAN-Basisadresse für QR-Uploads eingeben.
|
||||
6. optional FLUX aktivieren.
|
||||
7. **Installieren** anklicken.
|
||||
8. Erst-Admin-Code aus der Zwischenablage bei der ersten Einrichtung einfügen.
|
||||
|
||||
Node.js wird geprüft. Fehlt Node.js, bietet der bestehende Installer eine automatische Installation an.
|
||||
|
||||
## Windows mit Docker Desktop
|
||||
|
||||
1. Docker Desktop starten.
|
||||
2. `setup.bat` doppelklicken.
|
||||
3. **Docker Desktop auf diesem Windows-PC** wählen.
|
||||
4. Zugriff nur lokal oder im privaten LAN festlegen.
|
||||
5. Port und optional QR-Basisadresse festlegen.
|
||||
6. **Installieren** anklicken.
|
||||
|
||||
Der Assistent erzeugt `.env`, Setup-Code und Installationsmodus automatisch. Die App bleibt standardmäßig nur auf `127.0.0.1` erreichbar.
|
||||
|
||||
## Linux oder macOS mit Docker
|
||||
|
||||
```sh
|
||||
chmod +x setup.sh
|
||||
./setup.sh
|
||||
```
|
||||
|
||||
Im Menü **Docker auf Linux/macOS/Docker Desktop** wählen. Der Assistent fragt Port und FLUX-Konfiguration ab und startet anschließend Compose.
|
||||
|
||||
## NAS / Portainer
|
||||
|
||||
1. Vendoo-Ordner auf das NAS kopieren.
|
||||
2. im Ordner `chmod +x setup.sh && ./setup.sh` ausführen.
|
||||
3. **NAS / Portainer / privates LAN** wählen.
|
||||
4. Port und LAN-Basisadresse eingeben.
|
||||
5. Installation starten.
|
||||
|
||||
Der Assistent legt automatisch folgende sichtbare Runtime-Verzeichnisse an:
|
||||
|
||||
- `runtime/db`
|
||||
- `runtime/uploads`
|
||||
- `runtime/backups`
|
||||
- `runtime/operations`
|
||||
- `runtime/logs`
|
||||
- `runtime/config`
|
||||
|
||||
Diese Verzeichnisse werden bei Updates nicht gelöscht.
|
||||
|
||||
## VPS mit automatischem HTTPS
|
||||
|
||||
Voraussetzungen:
|
||||
|
||||
- Domain zeigt per DNS auf den VPS,
|
||||
- Ports 80 und 443 sind erreichbar,
|
||||
- Docker Engine und Compose-Plugin sind installiert.
|
||||
|
||||
Ablauf:
|
||||
|
||||
```sh
|
||||
chmod +x setup.sh
|
||||
./setup.sh
|
||||
```
|
||||
|
||||
Dann **VPS / öffentlicher Server mit automatischem HTTPS** wählen und den Domainnamen ohne Protokoll eingeben. Der integrierte Caddy-Stack beantragt und erneuert TLS-Zertifikate automatisch. Vendoo selbst veröffentlicht Port 8124 nicht direkt ins Internet.
|
||||
|
||||
## Persistenter Konfigurationsspeicher
|
||||
|
||||
Im lokalen Windows-Betrieb verwendet Vendoo weiterhin die lokale `.env`. In Docker setzt der Installer automatisch:
|
||||
|
||||
```text
|
||||
VENDOO_CONFIG_PATH=/app/data/config/vendoo.env
|
||||
```
|
||||
|
||||
Die Eingabemasken schreiben dort ihre Werte mit restriktiven Dateirechten. Das Haupt-Dateisystem des Containers bleibt schreibgeschützt.
|
||||
|
||||
## Backup und sensible Konfiguration
|
||||
|
||||
Normale Docker-Backups enthalten Datenbank, Uploads, Backups, Operations und Logs. Der persistente Runtime-Konfigurationsspeicher mit API-/SMTP-/Marktplatzschlüsseln wird bewusst nicht in das normale Datenarchiv aufgenommen, damit ein weitergegebenes Backup nicht automatisch alle Zugangsdaten enthält.
|
||||
|
||||
Bei einer Wiederherstellung auf einem neuen System werden Betriebswerte durch den Installationsassistenten neu erzeugt und externe Zugangsdaten anschließend über **Vendoo → Einstellungen** erneut eingetragen. Dazu muss keine Datei manuell bearbeitet werden.
|
||||
|
||||
## Updates
|
||||
|
||||
Im Linux-/NAS-/VPS-Assistenten erstellt **Aktualisieren** zuerst automatisch ein Sicherheitsbackup. Danach werden Image beziehungsweise Quellcontainer neu gebaut, gestartet und über `/readyz` geprüft.
|
||||
|
||||
Unter Windows bleibt der bestehende Update- und Rollback-Ablauf erhalten.
|
||||
|
||||
## Nicht automatisch verändert
|
||||
|
||||
- Datenbank
|
||||
- Uploads und Originalbilder
|
||||
- Benutzer
|
||||
- Artikel
|
||||
- Backups
|
||||
- Operations-Daten
|
||||
- FLUX-Modelle
|
||||
- ComfyUI-Daten
|
||||
- API-Schlüssel
|
||||
@@ -0,0 +1,31 @@
|
||||
# Vendoo Listings UI 2026
|
||||
|
||||
## Ziel
|
||||
|
||||
Die Listings-/Historie-Seite bildet die operative Übersicht aller Artikel. Sie folgt der freigegebenen Vendoo-Designsprache und ersetzt die alte Kartenliste durch eine dichte, bildorientierte Arbeitsliste.
|
||||
|
||||
## Funktionsumfang
|
||||
|
||||
- Volltextsuche über bestehende Listing-Suche
|
||||
- Plattform- und Statusfilter
|
||||
- Zeiträume 7, 30 und 90 Tage, aktuelles Jahr, gesamter Zeitraum und benutzerdefinierte Daten
|
||||
- Spaltenkonfiguration mit Speicherung im Browser
|
||||
- Seitengrößen 10, 20, 50 oder alle
|
||||
- Seitennavigation mit direkten Seitenschaltflächen
|
||||
- Auswahl einzelner Listings und Auswahl der aktuellen Seite
|
||||
- Batch Publish, Nachbearbeiten, Preisänderung, Statusänderung, Duplizieren, Etikettendruck und Löschen
|
||||
- CSV- und JSON-Export
|
||||
- Direktänderung des Status pro Tabellenzeile
|
||||
- Zeilenaktionen Öffnen, Duplizieren und Löschen
|
||||
- Publish-Status-Badges je Plattform
|
||||
|
||||
## Technische Regeln
|
||||
|
||||
Die Umsetzung bleibt vollständig in der bestehenden Vanilla-Architektur:
|
||||
|
||||
- Markup: `public/index.html`
|
||||
- Verhalten: `public/app.js`
|
||||
- Design: `public/style.css`
|
||||
- keine neuen Frameworks
|
||||
- keine Änderungen am Datenbankschema erforderlich
|
||||
- vorhandene API-Endpunkte und CSRF-Absicherung werden weiterverwendet
|
||||
@@ -0,0 +1,28 @@
|
||||
# Vendoo Publish-Center 2026
|
||||
|
||||
## Ziel
|
||||
|
||||
Das Publish-Center bündelt alle Arbeitsschritte zwischen fertigem Listing und Veröffentlichung in einer einzigen, kontextstabilen Oberfläche.
|
||||
|
||||
## Bereiche
|
||||
|
||||
- **Smart Copy:** Felder, HTML/Text, Fotos und Plattformwechsel
|
||||
- **Direkt veröffentlichen:** Etsy- und eBay-API mit vorheriger Datenprüfung
|
||||
- **eBay Queue:** Status, Fehler, Wiederholungen und Verarbeitung
|
||||
- **Geplant:** zeitgesteuerte Veröffentlichungen mit Plattform und Zeitpunkt
|
||||
|
||||
## UX-Regeln
|
||||
|
||||
- keine internen Arbeitsabläufe in neuen Browserfenstern
|
||||
- Produktbild, Titel und SKU bleiben im Kontext sichtbar
|
||||
- Fehler und fehlende Pflichtfelder sind direkt handlungsfähig
|
||||
- externe Plattformen öffnen nur dann einen neuen Tab, wenn die Plattform selbst benötigt wird
|
||||
- alle Statusfarben verwenden die zentralen Vendoo-Tokens
|
||||
|
||||
## Technische Grundlage
|
||||
|
||||
- Vanilla JavaScript in `public/app.js`
|
||||
- Markup in `public/index.html`
|
||||
- Design-Tokens und responsive Komponenten in `public/style.css`
|
||||
- bestehende Endpunkte für Smart Copy, Etsy, eBay Queue und Scheduling
|
||||
- Session-, Rollen- und CSRF-Schutz bleiben unverändert aktiv
|
||||
@@ -0,0 +1,50 @@
|
||||
# Vendoo 1.24.0 – Responsive UI, FLUX-Auftragsarchiv und Bildergalerie
|
||||
|
||||
## Ziel
|
||||
|
||||
Version 1.24.0 schließt konkrete Bedienungs- und Verwaltungsprobleme zwischen Slice 31 und dem späteren Batch-Image-Slice. Der Release verändert keine bestehende FLUX-Modellinstallation und führt keine Virtual-Try-on-Funktion ein.
|
||||
|
||||
## Responsive Härtung
|
||||
|
||||
Die bisherige Listing-Tabelle erzwang auf kleineren Ansichten eine Mindestbreite von bis zu 1080 Pixeln. Unterhalb von 860 Pixeln wird sie nun als Kartenliste dargestellt. Plattform, Provider, Preis, Status, Lagerort und Aktualisierung bleiben als beschriftete Zeilen lesbar. Benutzerdefiniert ausgeblendete Spalten bleiben auch mobil ausgeblendet.
|
||||
|
||||
Zusätzlich wurden Breiten, Umbrüche und Overflow-Verhalten für Filterleisten, Batch-Aktionen, Pagination, FLUX-Job-Center, Galerie, Formulare und zentrale Arbeitsbereiche abgesichert.
|
||||
|
||||
## Hintergrundentfernung
|
||||
|
||||
`background_sensitivity` wird als Wert von 0 bis 100 in den nicht destruktiven Bearbeitungsparametern gespeichert. Vorschau und Sharp-Rendering verwenden dieselbe dynamische Schwellwert- und Feather-Logik.
|
||||
|
||||
- niedriger Wert: konservative Entfernung, mehr Kantenschutz
|
||||
- hoher Wert: aggressivere Entfernung ähnlicher Hintergrundfarben
|
||||
|
||||
## FLUX-Auftragsarchiv
|
||||
|
||||
Die additive Spalte `flux_prompt_jobs.archived_at` trennt aktive Historie und Archiv. Nur terminale Aufträge können archiviert werden. Laufende, wartende oder abbrechende Aufträge werden serverseitig übersprungen.
|
||||
|
||||
Funktionen:
|
||||
|
||||
- einzeln oder gesammelt archivieren
|
||||
- einzeln oder gesammelt wiederherstellen
|
||||
- einzelne oder mehrere archivierte Aufträge löschen
|
||||
- gesamtes Archiv löschen
|
||||
- serverseitige Pagination und Statusfilter
|
||||
- erzeugte Bilder bleiben beim Löschen von Auftragsmetadaten erhalten
|
||||
|
||||
## Bildergalerie
|
||||
|
||||
Der neue Navigationsbereich „Bilder“ aggregiert vorhandene Dateien aus:
|
||||
|
||||
- `flux_images`
|
||||
- `image_edit_versions`
|
||||
- `ai_model_photos`
|
||||
- den Fotoverweisen aktiver Listings
|
||||
|
||||
Doppelte Dateipfade werden zusammengeführt und mit mehreren Quellen-Badges dargestellt. Die Galerie bietet Raster-/Listenansicht, Suche, Quellenfilter, Favoriten, Sortierung, Pagination, Mehrfachauswahl, ZIP-Download, Lightbox, Editor-Übergabe und Generator-Übernahme. Dateien aktiver Listings werden beim Löschen geschützt.
|
||||
|
||||
## Nicht enthalten
|
||||
|
||||
- keine FASHN- oder VTO-Engine
|
||||
- keine Änderung an FLUX-Modellen
|
||||
- keine Datenbank-, Upload-, Listing- oder Schlüsselbereinigung
|
||||
- keine Hintergrundjobs außerhalb des bestehenden Vendoo-Prozesses
|
||||
- keine reale Windows-, GPU- oder ComfyUI-Abnahme ohne Nutzerausgaben
|
||||
@@ -0,0 +1,84 @@
|
||||
{
|
||||
"release": "1.24.0",
|
||||
"date": "2026-07-08",
|
||||
"checks": {
|
||||
"javascript_and_esm_syntax": {
|
||||
"status": "passed",
|
||||
"files": 51
|
||||
},
|
||||
"json_validation": {
|
||||
"status": "passed",
|
||||
"files": 18
|
||||
},
|
||||
"html_ids": {
|
||||
"status": "passed",
|
||||
"total": 592,
|
||||
"unique": 592,
|
||||
"duplicates": 0
|
||||
},
|
||||
"css_structure": {
|
||||
"status": "passed",
|
||||
"opening_braces": 2471,
|
||||
"closing_braces": 2471
|
||||
},
|
||||
"responsive_listing_rules": {
|
||||
"status": "passed",
|
||||
"mobile_card_layout": true,
|
||||
"fixed_minimum_width_removed_below_1180": true,
|
||||
"hidden_column_preferences_preserved": true
|
||||
},
|
||||
"background_removal_sensitivity": {
|
||||
"status": "passed",
|
||||
"low_sensitivity_transparent_pixels": 60256,
|
||||
"high_sensitivity_transparent_pixels": 80660,
|
||||
"higher_value_removes_more": true
|
||||
},
|
||||
"database_migration": {
|
||||
"status": "passed",
|
||||
"additive_column": "flux_prompt_jobs.archived_at",
|
||||
"existing_flux_image_preserved": true
|
||||
},
|
||||
"flux_archive_semantics": {
|
||||
"status": "passed",
|
||||
"terminal_jobs_archivable": true,
|
||||
"active_jobs_protected": true,
|
||||
"restore": true,
|
||||
"single_delete": true,
|
||||
"multi_delete": true,
|
||||
"delete_all": true,
|
||||
"generated_images_retained_by_design": true
|
||||
},
|
||||
"media_library": {
|
||||
"status": "passed",
|
||||
"sources": ["flux", "edited", "ai", "listing"],
|
||||
"search": true,
|
||||
"filters": true,
|
||||
"favorites": true,
|
||||
"grid_and_list": true,
|
||||
"pagination": true,
|
||||
"multi_select": true,
|
||||
"zip_download": true,
|
||||
"lightbox": true,
|
||||
"editor_handoff": true,
|
||||
"listing_image_delete_protection": true
|
||||
},
|
||||
"vinted_extension_regression_guard": {
|
||||
"status": "passed",
|
||||
"variants": 5,
|
||||
"title_field_protection_present": true,
|
||||
"extension_version_changed": false
|
||||
},
|
||||
"package_sources": {
|
||||
"status": "passed",
|
||||
"registry": "https://registry.npmjs.org/",
|
||||
"internal_openai_or_artifactory_sources": false
|
||||
}
|
||||
},
|
||||
"not_claimed": [
|
||||
"real Windows PowerShell 5.1 acceptance",
|
||||
"real browser interaction on the user's installation",
|
||||
"real NVIDIA GPU acceptance",
|
||||
"real ComfyUI queue/history acceptance",
|
||||
"real mapped-drive W: acceptance"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,59 @@
|
||||
# Vendoo 1.25.0 – Responsive Detail Editor, Gallery UX, Smart Copy und FLUX Prompt Lab
|
||||
|
||||
## Ziel
|
||||
|
||||
Version 1.25.0 korrigiert die verbliebenen Breitenprobleme in der Listing-Bearbeitung und überarbeitet mehrere Bedienwege, die im produktiven Einsatz unruhig, zu eng oder nicht mehr erreichbar waren. Der Release baut auf 1.24.0 auf und bleibt vollständig als Drüberkopier-Update installierbar.
|
||||
|
||||
## Listing-Bearbeitung
|
||||
|
||||
- Der Detail-Editor reagiert per Container Query auf die tatsächlich verfügbare Inhaltsbreite und nicht nur auf die gesamte Browserbreite.
|
||||
- Fotoleiste, Listing-Daten, Beschreibung, Plattformvorschau und Kontextkarten reduzieren sich kontrolliert von drei auf zwei und schließlich eine Spalte.
|
||||
- Formularfelder, Quill-Werkzeugleiste, Iframes, Textbereiche, Aktionsleisten und lange Inhalte besitzen konsequente `min-width: 0`- und Umbruchregeln.
|
||||
- Zusätzliche Media-Query-Fallbacks halten den Editor auch in Browsern ohne aktive Container-Query-Auswertung bedienbar.
|
||||
|
||||
## Bildergalerie
|
||||
|
||||
- Auswahlfelder sind als präzise eigene Checkbox-Komponente umgesetzt und liegen sauber innerhalb der Bildfläche.
|
||||
- Favoriten befinden sich als separates Overlay oben rechts.
|
||||
- Die große Vorschauaktion liegt als eindeutige, zentrierte Leiste unten im Bild und kollidiert nicht mit Auswahl oder Favorit.
|
||||
- Titel können über zwei Zeilen laufen; Metadaten werden sauber gekürzt.
|
||||
- Bearbeiten, Verwenden, Download und Löschen stehen in einem stabilen 2×2-Aktionsraster.
|
||||
- Raster- und Listenansicht sowie mobile Ein- und Zweispaltenansichten bleiben erhalten.
|
||||
|
||||
## Publish und Smart Copy
|
||||
|
||||
- Aktualisieren verwendet einen ruhigen Ladezustand mit Text und `aria-busy`; der gesamte Button rotiert nicht mehr.
|
||||
- Smart Copy öffnet wieder in einem eigenen responsiven Modal.
|
||||
- Das Modal enthält Titel, Beschreibung, Tags, Metadaten, Fotos, Kopieraktionen, Plattformstart und Veröffentlichungsstatus.
|
||||
- Vorheriges/nächstes Listing kann direkt im Modal gewechselt werden.
|
||||
- Nach dem Markieren als veröffentlicht wird das Modal sauber geschlossen und der Publish-Bereich neu geladen.
|
||||
|
||||
## FLUX Studio
|
||||
|
||||
### Ergebnisse & Favoriten
|
||||
|
||||
- Serverseitige Pagination mit 5, 10 oder 15 Bildern pro Seite.
|
||||
- Vorherige-/Nächste-Navigation und aktuelle Seitenangabe.
|
||||
- Favoritenfilter und Löschaktionen laden die korrekte Seite neu.
|
||||
|
||||
### Job-Center
|
||||
|
||||
- Aktive Aufträge und Archiv verwenden kompakte Seitengrößen von 5, 10 oder 15 Einträgen.
|
||||
- Bestehende Archiv-, Wiederherstellungs-, Mehrfachauswahl- und Löschfunktionen bleiben erhalten.
|
||||
|
||||
### Prompt Lab
|
||||
|
||||
- Der bisherige einfache Prompt-Verbesserer öffnet ein eigenes Prompt Lab.
|
||||
- Lokale Strukturierung funktioniert ohne API-Aufruf.
|
||||
- AI-Veredelung nutzt den aktuell aktiven Text-Provider: Claude, OpenAI, OpenRouter oder Ollama.
|
||||
- Profile: präzise, Produkt/Marketplace, kreativ und cinematisch.
|
||||
- Optionaler Schutz der Motividentität sowie Vermeidung erfundener Texte, Logos und Wasserzeichen.
|
||||
- Ergebnis, Provider, Modell und kurze AI-Hinweise werden sichtbar dargestellt.
|
||||
- Der optimierte Prompt kann direkt zurück ins FLUX Studio übernommen werden.
|
||||
|
||||
## Unveränderte Sperrregeln
|
||||
|
||||
- Kein FASHN VTON und kein Virtual Try-on.
|
||||
- FLUX bleibt ein freier Prompt-Bildgenerator.
|
||||
- Keine Datenbank, Listings, Uploads, `.env`, Schlüssel, ComfyUI-Installation oder FLUX-Modelle werden entfernt.
|
||||
- Keine internen Paketquellen.
|
||||
@@ -0,0 +1,30 @@
|
||||
{
|
||||
"release": "1.25.0",
|
||||
"static_checks": {
|
||||
"javascript_esm_syntax_files": 51,
|
||||
"json_files": 18,
|
||||
"unique_html_ids": 612,
|
||||
"duplicate_html_ids": 0,
|
||||
"css_brace_depth": 0
|
||||
},
|
||||
"functional_mock_checks": {
|
||||
"database_migrations": true,
|
||||
"flux_slice30_mock": true,
|
||||
"advanced_image_editor_render": true,
|
||||
"background_sensitivity_low_vs_high": true,
|
||||
"listing_editor_container_responsive": true,
|
||||
"gallery_card_controls": true,
|
||||
"smart_copy_modal": true,
|
||||
"publish_refresh_without_whole_button_rotation": true,
|
||||
"flux_history_page_sizes": [5, 10, 15],
|
||||
"flux_job_page_sizes": [5, 10, 15],
|
||||
"prompt_lab_providers": ["claude", "openai", "openrouter", "local"],
|
||||
"vinted_title_guard_preserved": true
|
||||
},
|
||||
"not_claimed_as_real_acceptance": [
|
||||
"Windows PowerShell 5.1 update on W drive",
|
||||
"interactive browser acceptance with user data",
|
||||
"real AI provider request",
|
||||
"real NVIDIA GPU or ComfyUI render"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,5 @@
|
||||
# Vendoo 1.25.1 – Adaptive Bildergalerie
|
||||
|
||||
Dieser Hotfix ersetzt die bisherige Galerie-Kartenkomponente vollständig. Das Raster berechnet Kartenanzahl und Kartenbreite automatisch aus dem tatsächlich verfügbaren Platz. Die gesamte Bildfläche ist die Vorschauaktion. Auswahl und Favorit bleiben als kompakte, skalierende Overlays erhalten. Die vier Bildaktionen bilden ein responsives Aktionsdock. Die Seitennavigation ist oberhalb und unterhalb der Galerie vorhanden und erlaubt einen direkten Sprung zu jeder Seite.
|
||||
|
||||
Die Umsetzung orientiert sich an etablierten Karten-, Auswahl- und Paginierungsmustern: Inhalt und Aktionen gehören zu einer klar scanbaren Karte, Auswahl wird durch Checkbox plus Oberflächenzustand angezeigt und Pagination gibt sowohl Seitengröße als auch direkte Navigation vor.
|
||||
@@ -0,0 +1,34 @@
|
||||
{
|
||||
"release": "1.25.1",
|
||||
"package_type": "full_overlay_update",
|
||||
"checks": {
|
||||
"javascript_syntax": "passed",
|
||||
"json_validity": "passed",
|
||||
"html_unique_ids": "passed",
|
||||
"css_parse": "passed",
|
||||
"gallery_static_release_gate": "passed",
|
||||
"database_migrations": "passed",
|
||||
"existing_database_row_preserved": "passed",
|
||||
"flux_archive_semantics": "passed",
|
||||
"runtime_data_excluded": "passed"
|
||||
},
|
||||
"gallery": {
|
||||
"adaptive_auto_fit_grid": true,
|
||||
"card_container_queries": true,
|
||||
"full_image_click_target": true,
|
||||
"legacy_open_button_removed": true,
|
||||
"adaptive_selection_overlay": true,
|
||||
"adaptive_favorite_overlay": true,
|
||||
"adaptive_action_dock": true,
|
||||
"pagination_top_and_bottom": true,
|
||||
"direct_page_jump": true,
|
||||
"touch_behavior": true,
|
||||
"keyboard_accessibility": true
|
||||
},
|
||||
"not_claimed": [
|
||||
"real Windows update on W drive",
|
||||
"interactive production browser acceptance",
|
||||
"native npm regression suite in this build environment"
|
||||
],
|
||||
"note": "The native npm regression suite could not be reinstalled in the build environment because external better-sqlite3 build artifacts were temporarily unreachable. This hotfix changes only frontend HTML, CSS and gallery JavaScript; syntax, static release gates and additive database migration tests passed."
|
||||
}
|
||||
@@ -0,0 +1,29 @@
|
||||
# Vendoo 1.26.0 – Artikel, Publish, Zoom-Galerie und Extension Center
|
||||
|
||||
## Ziel
|
||||
|
||||
Version 1.26.0 vereinheitlicht die Artikelbegriffe, repariert die Publish-/Smart-Copy-Wege, erweitert die Galerie um eine echte Zoom-Vorschau und führt eine zentrale Installation für Browser-Erweiterungen ein.
|
||||
|
||||
## Funktionsumfang
|
||||
|
||||
- **Neuer Artikel** direkt unter Dashboard; **Artikel** statt Listings
|
||||
- **Artikel generieren** statt Listing generieren
|
||||
- Publish lädt robuste Artikeldaten und verwendet im Direkt-Workspace den richtigen Container
|
||||
- Smart Copy als Popup mit vollständiger zentraler Vorschau
|
||||
- Galerie-Lightbox mit 10–400 %, Fit, 100 %, Mausrad und Drag-Panning
|
||||
- lokale Lucide-basierte SVG-Icons statt uneinheitlicher Symbolzeichen
|
||||
- aktualisierte Gebührenhinweise für private Verkäufer und Etsy-Shop-Kalkulation
|
||||
- Extensions-Seite mit aktiver Browsererkennung, Ordneröffnung, Pfadkopie und ZIP-Download
|
||||
- Safari Web Extension als Quelle mit Xcode-Konvertierungsskript
|
||||
|
||||
## Schutzregeln
|
||||
|
||||
Das Update enthält keine produktive `.env`, Datenbank, Listings, Uploads, API-Schlüssel, Logs, FLUX-Modelle oder `node_modules`. Bestehende Nutzerdaten werden nicht gelöscht.
|
||||
|
||||
## Noch real zu prüfen
|
||||
|
||||
- Installation und Browsercache auf dem Windows-Zielsystem
|
||||
- Publish mit den produktiven Artikeln
|
||||
- Smart Copy in den realen Plattformformularen
|
||||
- finale Browserbestätigung der Extensions
|
||||
- Safari-Konvertierung und Signierung auf einem Mac mit Xcode
|
||||
@@ -0,0 +1,36 @@
|
||||
{
|
||||
"release": "1.26.0",
|
||||
"date": "2026-07-08",
|
||||
"status": "static-gates-passed",
|
||||
"scope": [
|
||||
"article-navigation",
|
||||
"publish-hardening",
|
||||
"smart-copy-modal",
|
||||
"media-zoom",
|
||||
"fee-model",
|
||||
"extension-center",
|
||||
"safari-source"
|
||||
],
|
||||
"real_acceptance_pending": [
|
||||
"Windows update",
|
||||
"productive Publish data",
|
||||
"browser extension confirmation",
|
||||
"Safari Xcode conversion"
|
||||
],
|
||||
"javascript_esm_files": 59,
|
||||
"json_files": 22,
|
||||
"html_ids": 621,
|
||||
"duplicate_html_ids": 0,
|
||||
"css_rule_blocks": 2792,
|
||||
"extension_packages_verified": 4,
|
||||
"database_migration_blocks": 43,
|
||||
"existing_database_row_preserved": true,
|
||||
"fee_test_price_eur": 100,
|
||||
"fee_results": {
|
||||
"ebay_private": 0,
|
||||
"vinted_seller": 0,
|
||||
"kleinanzeigen_private": 0,
|
||||
"etsy_estimate": 10.8
|
||||
},
|
||||
"native_runtime_test": "not_run_dependency_download_unavailable"
|
||||
}
|
||||
@@ -0,0 +1,22 @@
|
||||
# Vendoo 1.26.1 – Stabilitäts-, Responsive- und Regression-Gate
|
||||
|
||||
## Ziel
|
||||
|
||||
Der Release friert den Funktionsstand 1.26.0 ein und schafft eine belastbare Grundlage für Batch Image Factory, Artikel Quality Center und Publishing Hardening. Es werden keine produktiven Daten oder bestehenden Workflows entfernt.
|
||||
|
||||
## Produktive Änderungen
|
||||
|
||||
- `GET /healthz` liefert ausschließlich Version, Laufzeit und Zeitstempel.
|
||||
- `GET /api/admin/diagnostics` prüft als Admin Datenbank, Dateisystem, Pflichtassets, Extensions, AI-Konfiguration und optional ComfyUI.
|
||||
- Der Browser-API-Client nutzt Request-IDs, Zeitlimits und einen begrenzten GET-Retry.
|
||||
- Netzwerkfehler werden sichtbar angezeigt und automatisch erneut geprüft.
|
||||
- Die letzten 30 Clientfehler werden lokal im Browser gespeichert und können mit der Systemdiagnose kopiert werden.
|
||||
- Ein `ResizeObserver` ordnet den realen Arbeitsbereich in `phone`, `narrow`, `compact`, `standard` oder `wide` ein.
|
||||
- Neue globale CSS-Verträge verhindern Überbreite in allen Hauptseiten.
|
||||
|
||||
## Sperrregeln
|
||||
|
||||
- Keine `.env`, Datenbank, Uploads, Listings, Schlüssel, Logs oder Modelle im Releasepaket.
|
||||
- Keine FASHN-/VTO-Funktion und kein `LoadImage` im freien FLUX-Workflow.
|
||||
- ComfyUI ist optional; Nichterreichbarkeit ist ein Hinweis und kein Vendoo-Kernfehler.
|
||||
- Diagnoseantworten geben keine API-Schlüssel oder Passwörter aus.
|
||||
@@ -0,0 +1,27 @@
|
||||
{
|
||||
"version": "1.26.1",
|
||||
"release": "Stability Responsive Regression Gate",
|
||||
"static_verification": true,
|
||||
"checks": {
|
||||
"health_endpoint": true,
|
||||
"admin_system_diagnostics": true,
|
||||
"sqlite_quick_check": true,
|
||||
"writable_path_probes": true,
|
||||
"extension_presence_four_browsers": true,
|
||||
"api_request_ids": true,
|
||||
"api_timeout": true,
|
||||
"get_retry_once": true,
|
||||
"client_error_capture": true,
|
||||
"workspace_resize_observer": true,
|
||||
"ui_contract_verifier": true,
|
||||
"database_migration_preservation": true,
|
||||
"vto_removed": true,
|
||||
"flux_workflow_without_loadimage": true
|
||||
},
|
||||
"real_acceptance_pending": [
|
||||
"Windows target installation",
|
||||
"interactive browser workflows",
|
||||
"real ComfyUI/GPU probe",
|
||||
"mapped W drive permissions"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,70 @@
|
||||
# Vendoo 1.30.0 – Operations Center
|
||||
|
||||
Version: 1.30.0
|
||||
|
||||
## Ziel
|
||||
|
||||
Vendoo erhält eine gemeinsame Betriebsgrundlage für verifizierte Sicherungen, kontrollierte Wiederherstellung, vorbereitete Offline-Updates, Rollback und Browser-Extension-Diagnose.
|
||||
|
||||
## Backup und Wiederherstellung
|
||||
|
||||
- vollständige Backups mit Datenbank, optionalen Uploads und optionaler `.env`
|
||||
- reine Datenbank-Backups
|
||||
- SQLite-Snapshot über die native Backup-Funktion
|
||||
- `backup-manifest.json` mit SHA-256 je Datei
|
||||
- SQLite-`integrity_check` vor Freigabe eines Backups
|
||||
- manuelle Verifikation bereits erstellter Backups
|
||||
- Download und kontrollierte Löschung
|
||||
- automatische tägliche Sicherungen mit einstellbarer Uhrzeit und Rotation
|
||||
- Wiederherstellung nur nach erfolgreicher Archivprüfung
|
||||
- automatische Sicherheitssicherung vor jeder vorbereiteten Wiederherstellung
|
||||
- Wiederherstellung wird ausschließlich offline über `setup.bat` Menüpunkt 11 angewendet
|
||||
|
||||
## Update Center
|
||||
|
||||
- installierte Version und registrierte Migrationen
|
||||
- optionale Online-Prüfung über `VENDOO_UPDATE_MANIFEST_URL`
|
||||
- lokaler Upload eines vollständigen Vendoo-ZIP-Pakets
|
||||
- Prüfung auf gültiges Vendoo-Paket und höhere Zielversion
|
||||
- Blockade von `.env`, Datenbank, Uploads, Backups, Logs, Modellen und `node_modules` im Update-Archiv
|
||||
- verpflichtendes Backup-Gate vor dem Staging
|
||||
- Offline-Anwendung über Setup-Menüpunkt 11
|
||||
- Code- und Laufzeit-Snapshot vor dem eigentlichen Austausch
|
||||
- automatische Rückkehr zum vorherigen Stand bei einem Apply-Fehler
|
||||
- manueller Rollback über Setup-Menüpunkt 12
|
||||
|
||||
## Extension-Diagnose
|
||||
|
||||
Vendoo Link 1.9.0 meldet lokale Heartbeats mit:
|
||||
|
||||
- Browserfamilie
|
||||
- Extension-Version
|
||||
- Plattformkontext
|
||||
- letzter Aktivität
|
||||
- Client-ID
|
||||
|
||||
Der Diagnosebereich zeigt erwartete und erkannte Versionen, zuletzt aktive Clients und fehlende beziehungsweise veraltete Verbindungen. Es werden keine Seiteninhalte, Passwörter oder API-Schlüssel übertragen.
|
||||
|
||||
## Datenbank
|
||||
|
||||
Neue additive Tabellen:
|
||||
|
||||
- `operation_backups`
|
||||
- `operation_settings`
|
||||
- `update_operations`
|
||||
- `system_migrations`
|
||||
- `extension_clients`
|
||||
|
||||
Registrierte Migration:
|
||||
|
||||
- `operations-center-1.30.0`
|
||||
|
||||
Bestehende Artikel, Bilder, FLUX-Aufträge, Publishing-Aufträge und Einstellungen werden nicht gelöscht.
|
||||
|
||||
## Sicherheitsgrenzen
|
||||
|
||||
- Sicherungen mit `.env` enthalten Zugangsdaten und müssen vertraulich behandelt werden.
|
||||
- Ein Restore oder Update wird nicht während des laufenden Vendoo-Servers angewendet.
|
||||
- Update- und Restore-Archive werden zunächst in einen lokalen Staging-Bereich geschrieben und geprüft.
|
||||
- ZIP-Pfadmanipulationen und absolute Archivpfade werden blockiert.
|
||||
- Vendoo behauptet keine reale Windows-, PowerShell-, Restore-, Update- oder Rollback-Abnahme ohne Bestätigung auf dem Zielsystem.
|
||||
@@ -0,0 +1,32 @@
|
||||
{
|
||||
"ok": true,
|
||||
"version": "1.30.0",
|
||||
"js_files": 72,
|
||||
"json_files": 28,
|
||||
"html_ids": 759,
|
||||
"css_blocks": 3237,
|
||||
"nav_targets": 16,
|
||||
"extension_packages": 4,
|
||||
"operations_markers": 59,
|
||||
"verified_sqlite_backups": true,
|
||||
"backup_manifest_sha256": true,
|
||||
"automatic_rotation": true,
|
||||
"restore_safety_backup": true,
|
||||
"update_backup_gate": true,
|
||||
"offline_apply": true,
|
||||
"rollback_foundation": true,
|
||||
"extension_heartbeat": true,
|
||||
"zip_traversal_guard": true,
|
||||
"native_runtime_test": false,
|
||||
"native_runtime_test_reason": "Das produktive better-sqlite3-Modul und node_modules sind in der Build-Umgebung nicht vorhanden. Migrationen wurden mit SQLite und die JavaScript-/Archivlogik statisch beziehungsweise isoliert geprüft.",
|
||||
"powershell_parser_test": false,
|
||||
"powershell_parser_test_reason": "PowerShell 5.1 beziehungsweise pwsh ist in der Build-Umgebung nicht verfügbar. setup.bat enthält weiterhin den Parser-Guard für das Windows-Zielsystem.",
|
||||
"real_target_acceptance": {
|
||||
"windows_setup": false,
|
||||
"backup_creation": false,
|
||||
"restore_apply": false,
|
||||
"update_apply": false,
|
||||
"rollback": false,
|
||||
"extension_heartbeat": false
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,28 @@
|
||||
# Vendoo 1.31.0 – Mehrbenutzer- und Server-Sicherheitsgrundlage
|
||||
|
||||
## Ziel
|
||||
|
||||
Version 1.31.0 führt eine belastbare Grundlage für mehrere Benutzer und einen bewusst freigegebenen LAN-/Serverbetrieb ein. Bestehende Daten werden additiv migriert.
|
||||
|
||||
## Rollen
|
||||
|
||||
- Administrator: Vollzugriff einschließlich Benutzer, Sitzungen, Backups, Updates und Sicherheit.
|
||||
- Manager: operative Leitung ohne Benutzer- und Systemverwaltung.
|
||||
- Editor: Artikel, Medien, AI/FLUX, Bildproduktion und Qualität.
|
||||
- Publisher: Prüfung und Veröffentlichung bei schreibgeschützten Artikelstammdaten.
|
||||
- Leser: reiner Lesezugriff.
|
||||
|
||||
## Sicherheitsverträge
|
||||
|
||||
- Jede geschützte API wird serverseitig auf eine Berechtigung geprüft.
|
||||
- Sitzungen besitzen absolute und inaktive Laufzeiten und können widerrufen werden.
|
||||
- Wiederholte Fehlanmeldungen sperren das Konto zeitweise.
|
||||
- Neue Passwörter benötigen mindestens zehn Zeichen, Klein-/Großbuchstaben, Zahl und Sonderzeichen.
|
||||
- Artikelbearbeitung verwendet kurzlebige persistente Sperren.
|
||||
- Standard-Bind-Adresse ist `127.0.0.1`; LAN-Betrieb muss ausdrücklich aktiviert werden.
|
||||
- Host, Origin, Proxy-Vertrauen und Rate Limits sind über `.env` konfigurierbar.
|
||||
- Sicherheitsrelevante Aktionen und verweigerte Berechtigungen werden protokolliert.
|
||||
|
||||
## Nicht Bestandteil dieser Abnahme
|
||||
|
||||
Ein realer Windows-/NAS-/Reverse-Proxy-Lauf, echtes HTTPS, Firewallregeln und parallele Browser-Sitzungen müssen auf dem Zielsystem geprüft werden.
|
||||
@@ -0,0 +1,31 @@
|
||||
{
|
||||
"release": "Vendoo Multiuser & Security Foundation",
|
||||
"version": "1.31.0",
|
||||
"status": "static_and_sqlite_verified",
|
||||
"verified": [
|
||||
"all JavaScript and ESM files pass node --check",
|
||||
"all JSON files parse successfully",
|
||||
"public/index.html contains no duplicate IDs",
|
||||
"CSS braces are balanced",
|
||||
"five fixed roles and permission catalog are present",
|
||||
"API permission guard and rate limiter are active",
|
||||
"password policy, account lockout, session expiry and revocation are present",
|
||||
"persistent article edit locks are present",
|
||||
"audit filtering and CSV export are present",
|
||||
"default bind host is 127.0.0.1",
|
||||
"host/origin/proxy/session/rate settings are documented in .env.example",
|
||||
"SQLite additive migration preserves an existing listing",
|
||||
"resource lock uniqueness is enforced",
|
||||
"legacy database migration suite remains successful",
|
||||
"free FLUX workflow contains no LoadImage",
|
||||
"no active FASHN or Virtual Try-on implementation is included",
|
||||
"setup.ps1 contains exactly one UTF-8 BOM"
|
||||
],
|
||||
"not_claimed": [
|
||||
"real Windows PowerShell 5.1 acceptance",
|
||||
"real multi-browser concurrent edit test",
|
||||
"real NAS or public reverse proxy deployment",
|
||||
"real HTTPS and firewall acceptance",
|
||||
"native better-sqlite3 server startup in the build environment"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,91 @@
|
||||
# Vendoo 1.32.0 – Docker, NAS & Production Deployment Foundation
|
||||
|
||||
## Ziel
|
||||
|
||||
Vendoo kann weiterhin unverändert lokal unter Windows betrieben werden und zusätzlich reproduzierbar in Docker beziehungsweise Portainer laufen. Anwendungscode und persistente Nutzerdaten sind getrennt. FLUX/ComfyUI bleibt ein optionaler externer Dienst und wird nicht in den Vendoo-Hauptcontainer eingebaut.
|
||||
|
||||
## Neue Deployment-Bausteine
|
||||
|
||||
- mehrstufiges `Dockerfile` auf Node.js 22
|
||||
- reproduzierbare Installation über `npm ci` und Lockfile
|
||||
- Ausführung als nicht privilegierter Benutzer `node` (UID/GID 1000)
|
||||
- `read_only`-Container, `no-new-privileges`, alle Linux-Capabilities entfernt
|
||||
- getrennte persistente Volumes für DB, Uploads, Backups, Operations und Logs
|
||||
- `/healthz` für Liveness und `/readyz` für DB-/Schreibpfad-Readiness
|
||||
- geordneter SIGTERM-/SIGINT-Shutdown mit SQLite-WAL-Checkpoint
|
||||
- zentral konfigurierbare Laufzeitpfade, bei Windows aber identische Standardpfade wie zuvor
|
||||
- Erst-Admin-Schutz über einen mindestens 32 Zeichen langen `VENDOO_SETUP_TOKEN`; bis zur Einrichtung bleiben alle übrigen API-Routen gesperrt
|
||||
- konfigurierbare Secure-/SameSite-Cookies
|
||||
- kontrollierte Browser-Extension-Origin-Allowlist
|
||||
- Uploads nur noch nach Anmeldung abrufbar
|
||||
- strengere Bildannahme: zulässige Endung und Bild-MIME müssen zusammenpassen
|
||||
- Docker-Backup-/Restore-Hilfsskripte für Named Volumes und NAS-Bind-Mounts sowie ein Bind-Mount-Beispiel
|
||||
- begrenzte Docker-Logrotation (`10m`, fünf Dateien)
|
||||
|
||||
## Laufzeitpfade
|
||||
|
||||
| Variable | Docker-Standard | Windows ohne Variable |
|
||||
|---|---|---|
|
||||
| `VENDOO_DATA_DIR` | `/app/data` | Projektordner |
|
||||
| `VENDOO_DB_PATH` | `/app/data/db/vendoo.db` | `db/vendoo.db` |
|
||||
| `VENDOO_UPLOADS_DIR` | `/app/data/uploads` | `uploads/` |
|
||||
| `VENDOO_BACKUP_DIR` | `/app/data/backups` | `backups/` |
|
||||
| `VENDOO_OPERATIONS_DIR` | `/app/data/operations` | `operations/` |
|
||||
| `VENDOO_LOG_DIR` | `/app/data/logs` | `logs/` |
|
||||
|
||||
Leere Variablen fallen auf die kompatiblen Standardpfade zurück.
|
||||
|
||||
## Reverse Proxy
|
||||
|
||||
Der Compose-Port wird standardmäßig ausschließlich an `127.0.0.1` gebunden. Für ein NAS kann ein lokaler Reverse Proxy entweder denselben Docker-Netzwerkpfad verwenden oder der Host-Port bewusst im vertrauenswürdigen LAN bereitgestellt werden. Eine direkte öffentliche Portweiterleitung auf 8124 ist kein unterstützter Produktionsweg.
|
||||
|
||||
Erforderlich hinter HTTPS:
|
||||
|
||||
```env
|
||||
PUBLIC_BASE_URL=https://vendoo.example.de
|
||||
VENDOO_ALLOWED_HOSTS=vendoo.example.de
|
||||
VENDOO_ALLOWED_ORIGINS=https://vendoo.example.de
|
||||
VENDOO_TRUST_PROXY=1
|
||||
VENDOO_COOKIE_SECURE=true
|
||||
VENDOO_COOKIE_SAMESITE=lax
|
||||
```
|
||||
|
||||
`VENDOO_TRUST_PROXY=1` bedeutet genau einen vertrauenswürdigen Proxy-Hop. Bei anderer Topologie muss die reale Hop-Anzahl oder ein zulässiger Express-Proxybereich gesetzt werden.
|
||||
|
||||
## Browser-Erweiterungen
|
||||
|
||||
Im Produktionsmodus ist die pauschale Freigabe aller Extension-Origins deaktiviert. Konkrete IDs werden eingetragen, zum Beispiel:
|
||||
|
||||
```env
|
||||
VENDOO_EXTENSION_ORIGINS=chrome-extension://abcdefghijklmnop,moz-extension://uuid
|
||||
VENDOO_ALLOW_ANY_EXTENSION_ORIGIN=false
|
||||
```
|
||||
|
||||
Die bestehende Cookie-basierte Anmeldung bleibt kompatibel. Eine eigene widerrufbare Extension-Tokenkopplung ist bewusst nicht vorgezogen worden und bleibt Teil des späteren Extension Distribution Centers.
|
||||
|
||||
## FLUX/ComfyUI
|
||||
|
||||
Der Hauptcontainer startet standardmäßig mit:
|
||||
|
||||
```env
|
||||
LOCAL_IMAGE_ENABLED=false
|
||||
```
|
||||
|
||||
Für einen getrennten GPU-Dienst:
|
||||
|
||||
```env
|
||||
LOCAL_IMAGE_ENABLED=true
|
||||
LOCAL_IMAGE_URL=http://comfyui:8188
|
||||
LOCAL_IMAGE_TOKEN=<starkes-dienst-token>
|
||||
LOCAL_IMAGE_REQUIRE_TOKEN=true
|
||||
LOCAL_IMAGE_ALLOW_REMOTE=true
|
||||
```
|
||||
|
||||
ComfyUI darf nicht direkt öffentlich freigegeben werden. Das freie FLUX-Prompt-Workflow bleibt textbasiert; es wird kein Produktbild oder `LoadImage`-Knoten eingeschleust.
|
||||
|
||||
## Updateprinzip
|
||||
|
||||
- Windows: bestehender Drüberkopierablauf und `setup.bat` Menüpunkt 3 bleiben gültig.
|
||||
- Docker: Nutzervolumes bleiben bestehen; nur Image/Code wird neu gebaut und der Container ersetzt.
|
||||
- Vor jedem Update DB und Uploads gemeinsam sichern.
|
||||
- Bei fehlgeschlagener Readiness nicht weiterarbeiten, sondern Logs und Volume-Rechte prüfen und gegebenenfalls auf das vorherige Image zurückgehen.
|
||||
@@ -0,0 +1,35 @@
|
||||
{
|
||||
"schema": "vendoo-release-verification-v1",
|
||||
"version": "1.32.0",
|
||||
"date": "2026-07-09",
|
||||
"basis_sha256": "cad2670d663c98964b7c3b4e95e5f6e475a3bcae12921339a0a84576b77d325b",
|
||||
"basis_files_verified": 271,
|
||||
"passed": [
|
||||
"handover-read-order",
|
||||
"basis-sha256",
|
||||
"basis-file-checksums",
|
||||
"version-sync",
|
||||
"javascript-syntax",
|
||||
"shell-syntax",
|
||||
"yaml-static-parse",
|
||||
"fresh-db-migration",
|
||||
"existing-db-migration-data-preservation",
|
||||
"npm-lock-resolution-ignore-scripts",
|
||||
"runtime-path-writability",
|
||||
"setup-token-entrypoint",
|
||||
"deployment-static-gate",
|
||||
"data-hygiene",
|
||||
"secret-pattern-scan",
|
||||
"flux-separation-no-vto"
|
||||
],
|
||||
"not_executed": {
|
||||
"full-npm-ci-native-scripts": "better-sqlite3 native compilation exceeded sandbox execution limits after prebuild/network unavailability",
|
||||
"server-api-smoke": "native better-sqlite3 binary unavailable",
|
||||
"docker-build-compose-runtime": "docker command unavailable, exit 127",
|
||||
"windows-powershell-runtime": "Windows and PowerShell unavailable",
|
||||
"browser-ui-e2e": "browser runtime unavailable",
|
||||
"reverse-proxy-https-live": "proxy/TLS environment unavailable",
|
||||
"platform-api-publishing": "intentionally not triggered"
|
||||
},
|
||||
"release_position": "package-ready-for-real-environment-acceptance"
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
# Vendoo 1.33.0 – Multiplatform Deployment Wizard & Flux/Admin Fixes
|
||||
|
||||
Dieser Release ergänzt die Docker-/NAS-Grundlage aus 1.32.0 um native, geführte Installationswege für Windows, Docker Desktop, Linux, NAS/Portainer und VPS. Zusätzlich startet FLUX Studio neutral und die Benutzerbearbeitung wurde stabilisiert.
|
||||
|
||||
## Installer-Architektur
|
||||
|
||||
- Windows: `setup.bat` → `setup.ps1`
|
||||
- Linux/NAS/VPS: `setup.sh`
|
||||
- gemeinsamer Kern: `.env`, Compose, Volumes, Healthchecks, Backup und Restore
|
||||
- keine automatische unsichere Ferninstallation auf einen VPS
|
||||
- Zielsystemabhängige native Skripte statt zusätzlicher Pflicht für PowerShell 7 auf NAS/VPS
|
||||
|
||||
## FLUX
|
||||
|
||||
- keine automatische Auswahl aus der Bibliothek
|
||||
- Reset für Prompt, Einstellungen, Vorschau und Varianten
|
||||
- Verlauf und Jobs bleiben unverändert
|
||||
- FLUX bleibt ein separater Text-zu-Bild-Dienst
|
||||
|
||||
## Benutzerverwaltung
|
||||
|
||||
- stabile Listener nach jedem Rendern der Benutzerliste
|
||||
- sicher escaped Inhalte
|
||||
- konsistenter Benutzer-Cache
|
||||
- Vorabvalidierung für Passwortänderungen
|
||||
- sanitisierte Serverantwort nach Benutzeränderung
|
||||
@@ -0,0 +1,44 @@
|
||||
# Vendoo 1.34.0 – GitHub CI/CD & Zero-Edit Installation Foundation
|
||||
|
||||
## Ziel
|
||||
|
||||
Version 1.34.0 verbindet die vorhandene Multiplatform-Grundlage mit einer produktionsnahen GitHub- und Release-Struktur und beseitigt manuelle Konfigurationsschritte aus der Installation.
|
||||
|
||||
## Architektur
|
||||
|
||||
### Installation
|
||||
|
||||
- Windows: WinForms-Assistent über `setup-gui.ps1`.
|
||||
- Windows-Konsole: bestehendes Setup-Menü plus geführter Konfigurationspunkt.
|
||||
- Linux/macOS/NAS/VPS: POSIX-kompatibler Dialogassistent über `setup.sh`.
|
||||
- VPS: separater Compose-Stack mit Caddy und automatischem HTTPS.
|
||||
|
||||
### Konfiguration
|
||||
|
||||
- Deployment-Werte werden durch Installer in `.env` geschrieben.
|
||||
- App-Eingabemasken schreiben veränderliche Schlüssel in einen persistenten Runtime-Overlay-Speicher.
|
||||
- `bootstrap.mjs` lädt zuerst die Installationskonfiguration und danach den Runtime-Overlay.
|
||||
- Docker verwendet ein eigenes Volume `vendoo_config`.
|
||||
- Das Container-Root-Dateisystem bleibt read-only.
|
||||
|
||||
### GitHub
|
||||
|
||||
- CI auf Push und Pull Request.
|
||||
- Release-Automation auf veröffentlichte GitHub Releases.
|
||||
- GHCR-Images für AMD64 und ARM64 mit Digest-basierter Provenienz-Attestierung.
|
||||
- Dependabot für npm, GitHub Actions und Docker.
|
||||
- CODEOWNERS und Pull-Request-Checkliste.
|
||||
- kontrollierter Erstimport über Release-Branch.
|
||||
|
||||
## Sicherheitsentscheidungen
|
||||
|
||||
- Kein direkter Push des unkontrollierten Projektordners nach `main`.
|
||||
- Keine automatische VPS-Ferninstallation über gespeicherte SSH-Zugangsdaten.
|
||||
- Kein `latest`-Deployment ohne Release-Freigabe.
|
||||
- Kein Speichern von Secrets in GitHub-Workflowdateien.
|
||||
- Kein Aufweichen des read-only Containers für die Einstellungsmaske.
|
||||
- Keine automatische Aufnahme des Runtime-Secret-Stores in normale Backups.
|
||||
|
||||
## Bewusst offen
|
||||
|
||||
Ein echtes Production-CD mit SSH oder selbst gehostetem Runner ist nicht aktiviert. Es folgt erst nach praktischer NAS-/VPS-Abnahme mit Backup, Restore und Rollback.
|
||||
@@ -0,0 +1,51 @@
|
||||
{
|
||||
"release": "1.34.0",
|
||||
"date": "2026-07-09",
|
||||
"base": "1.33.0",
|
||||
"github": {
|
||||
"repository": "Masterluke77/vendoo",
|
||||
"branch": "release/1.34.0-initial-import",
|
||||
"draft_pull_request": 3,
|
||||
"status_commit": "c8f739afcff9024c1a7b66281484dc9cc1793394",
|
||||
"full_source_push_required": true
|
||||
},
|
||||
"checks": {
|
||||
"javascript_mjs_syntax": "passed",
|
||||
"shell_syntax": "passed",
|
||||
"yaml_parse": "passed",
|
||||
"git_safety": {
|
||||
"status": "passed",
|
||||
"files_checked": 314
|
||||
},
|
||||
"deployment_gate": "passed",
|
||||
"runtime_config_store": "passed",
|
||||
"shell_installer_simulation": {
|
||||
"status": "passed",
|
||||
"modes": [
|
||||
"docker",
|
||||
"nas",
|
||||
"vps"
|
||||
]
|
||||
},
|
||||
"database_migrations": {
|
||||
"status": "passed",
|
||||
"fresh_exec_blocks": 68,
|
||||
"existing_exec_blocks": 68,
|
||||
"existing_row_preserved": true
|
||||
},
|
||||
"release_builder": {
|
||||
"status": "passed",
|
||||
"files_hashed": 314
|
||||
}
|
||||
},
|
||||
"not_executed": [
|
||||
"Windows WinForms and PowerShell 5.1 runtime",
|
||||
"real Docker build and container start",
|
||||
"Docker Desktop runtime on Windows or macOS",
|
||||
"real Portainer/NAS import",
|
||||
"real Caddy TLS issuance and public DNS",
|
||||
"browser end-to-end test",
|
||||
"native better-sqlite3 Node runtime",
|
||||
"published GitHub Release and GHCR push"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,27 @@
|
||||
# Vendoo 1.34.1 – Git-Sicherheitsgate Windows Hotfix
|
||||
|
||||
## Anlass
|
||||
|
||||
Beim ersten praktischen Lauf des GitHub-Deploy-Assistenten unter Windows brach das Git-Sicherheitsgate mit einer pauschalen Fehlermeldung ab. Die Analyse zeigte zwei relevante Ursachen:
|
||||
|
||||
1. `new URL(...).pathname` lieferte unter Windows keinen zuverlässig nutzbaren Dateisystempfad.
|
||||
2. In einem geklonten Repository wurden bevorzugt nur bereits von Git verfolgte Dateien geprüft. Neu kopierte, noch unversionierte Dateien waren dadurch nicht Teil des erweiterten Secret-Scans.
|
||||
|
||||
## Korrektur
|
||||
|
||||
- Root-Pfade werden mit `fileURLToPath(import.meta.url)` erzeugt.
|
||||
- Das Gate scannt immer den vollständigen Arbeitsbaum vor `git add`.
|
||||
- Environment-Dateien wie `.env`, `.env.local`, `.env.production` und vergleichbare Varianten werden blockiert.
|
||||
- Der Deploy-Assistent verlangt Node.js und überspringt den erweiterten Scan nicht mehr.
|
||||
- Bei einem Treffer werden die konkreten Dateien angezeigt und zusätzlich nach `logs/github-deploy-safety-report.txt` geschrieben.
|
||||
- Ein Regressionstest erzeugt absichtlich unversionierte Test-Secrets und erwartet zwingend eine Blockierung.
|
||||
|
||||
## GitHub
|
||||
|
||||
- Neuer Importbranch: `release/1.34.1-initial-import`
|
||||
- Neuer Draft Pull Request: `#4`
|
||||
- Der alte Draft Pull Request `#3` wurde geschlossen und als ersetzt markiert.
|
||||
|
||||
## Datenhaltung
|
||||
|
||||
Der Hotfix verändert oder löscht keine Datenbank, Uploads, Backups, `.env`, API-Schlüssel, Benutzer, Artikel, FLUX-Modelle oder ComfyUI-Daten.
|
||||
@@ -0,0 +1,17 @@
|
||||
{
|
||||
"release": "1.34.1",
|
||||
"status": "passed_static_and_regression",
|
||||
"git": {
|
||||
"branch": "release/1.34.1-initial-import",
|
||||
"pull_request": 4,
|
||||
"supersedes_pull_request": 3
|
||||
},
|
||||
"checks": [
|
||||
"windows-safe fileURLToPath root",
|
||||
"full working-tree scan",
|
||||
"untracked secret regression",
|
||||
"deployment gate",
|
||||
"shell syntax",
|
||||
"version consistency"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,47 @@
|
||||
# Vendoo 1.34.2 – Git-Sicherheitsdiagnose & gemeinsamer Staging-Builder
|
||||
|
||||
## Anlass
|
||||
|
||||
Beim praktischen Windows-Lauf erschien nur:
|
||||
|
||||
```text
|
||||
Git-Sicherheitsgate fehlgeschlagen (4):
|
||||
```
|
||||
|
||||
Die Zahl `4` ist die Anzahl der gefundenen Treffer, nicht der Prozess-Exitcode. Windows PowerShell 5.1 behandelte die über stderr ausgegebenen Detailzeilen jedoch als Fehlerstrom und brach die Ausgabe nach der Überschrift ab.
|
||||
|
||||
Zusätzlich verwendeten Windows und Linux unterschiedliche Kopierregeln. Lokale `.env.*`-Dateien oder Operations-Laufzeitordner konnten dadurch zunächst in das temporäre Staging gelangen und wurden erst anschließend vom Gate blockiert.
|
||||
|
||||
## Lösung
|
||||
|
||||
### Einheitlicher Staging-Builder
|
||||
|
||||
`tools/prepare-git-staging.mjs` wird auf allen Plattformen verwendet. Er:
|
||||
|
||||
- erhält ausschließlich das `.git`-Verzeichnis des temporären Klons,
|
||||
- entfernt alte Dateien aus dem temporären Arbeitsbaum,
|
||||
- kopiert nur freigegebene Quelldateien,
|
||||
- übernimmt `.env.example` und `.env.docker.example`,
|
||||
- schließt produktive `.env.*`-Dateien aus,
|
||||
- schließt Operations-, Upload-, Backup-, Log-, Datenbank- und Modelllaufzeitdaten aus,
|
||||
- verändert niemals den echten Vendoo-Installationsordner.
|
||||
|
||||
### Vollständige Diagnose unter Windows
|
||||
|
||||
Der PowerShell-Assistent startet Node über `Start-Process` und leitet stdout und stderr in getrennte temporäre Dateien um. Anschließend werden alle Zeilen kontrolliert eingelesen und angezeigt.
|
||||
|
||||
Bei einem echten Treffer entsteht:
|
||||
|
||||
```text
|
||||
logs/github-deploy-safety-report.txt
|
||||
```
|
||||
|
||||
Der Bericht wird unter Windows automatisch im Editor geöffnet.
|
||||
|
||||
## Sicherheit
|
||||
|
||||
Der Filter ersetzt das Sicherheitsgate nicht. Nach dem bereinigten Kopiervorgang scannt `verify-git-safety.mjs` weiterhin den vollständigen Staging-Arbeitsbaum auf eingebettete Schlüssel, Tokens, private Schlüssel, unerwartet große Dateien und verbotene Laufzeitdaten.
|
||||
|
||||
## Datenhaltung
|
||||
|
||||
Der Hotfix verändert oder löscht keine Datenbank, Uploads, Backups, `.env`, API-Schlüssel, Benutzer, Artikel, FLUX-Modelle oder ComfyUI-Daten.
|
||||
@@ -0,0 +1,20 @@
|
||||
{
|
||||
"release": "1.34.2",
|
||||
"status": "passed_static_migration_and_regression",
|
||||
"git": {
|
||||
"branch": "release/1.34.2-initial-import",
|
||||
"pull_request": 5,
|
||||
"supersedes_pull_request": 4
|
||||
},
|
||||
"checks": [
|
||||
"shared cross-platform staging builder",
|
||||
"environment and runtime staging exclusions",
|
||||
"git metadata preservation",
|
||||
"complete Windows stdout and stderr diagnostics",
|
||||
"full working-tree secret scan",
|
||||
"untracked secret regression",
|
||||
"deployment gate",
|
||||
"shell installer simulation",
|
||||
"database migrations"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,17 @@
|
||||
# Vendoo 1.34.3 – Update-Archiv-Ausschluss
|
||||
|
||||
## Ursache
|
||||
|
||||
Lokale Update- und Slice-Sicherungen unter `updates/backups/` wurden vom Staging-Builder als normale Quelldateien behandelt. Das Sicherheitsgate blockierte anschließend darin enthaltene Installationsskripte korrekt.
|
||||
|
||||
## Lösung
|
||||
|
||||
- `updates/` wird im gemeinsamen Node-Staging-Builder vollständig ausgeschlossen.
|
||||
- Dieselbe Filterfunktion wird vom GitHub-Import und vom Release-Builder verwendet.
|
||||
- `.gitignore` enthält `updates/`.
|
||||
- Das Sicherheitsgate betrachtet `updates/` weiterhin als verbotenen Laufzeitpfad.
|
||||
- Ein Regressionstest bildet die drei real gemeldeten Dateien exakt nach.
|
||||
|
||||
## Datenwirkung
|
||||
|
||||
Der lokale Ordner `updates/` wird weder gelöscht noch verändert. Er wird ausschließlich nicht nach GitHub kopiert. Datenbank, Uploads, `.env`, Backups, Operations-Daten, FLUX-Modelle und ComfyUI-Daten bleiben unverändert.
|
||||
@@ -0,0 +1,33 @@
|
||||
{
|
||||
"release": "1.34.3",
|
||||
"date": "2026-07-09",
|
||||
"github": {
|
||||
"branch": "release/1.34.3-initial-import",
|
||||
"draft_pull_request": 6,
|
||||
"previous_pull_request_closed": 5
|
||||
},
|
||||
"checks": {
|
||||
"git_staging_regression": true,
|
||||
"exact_reported_paths_excluded": 3,
|
||||
"active_installer_files_preserved": [
|
||||
"setup.bat",
|
||||
"setup.ps1",
|
||||
"scripts/install-local-flux.ps1"
|
||||
],
|
||||
"git_safety_files_checked": 327,
|
||||
"migration_exec_blocks_fresh": 68,
|
||||
"migration_exec_blocks_existing": 68,
|
||||
"existing_row_preserved": true,
|
||||
"shell_installer_modes": [
|
||||
"docker",
|
||||
"nas",
|
||||
"vps"
|
||||
]
|
||||
},
|
||||
"not_runtime_tested": [
|
||||
"Windows PowerShell 5.1 on user machine",
|
||||
"real local Git push",
|
||||
"Docker/Portainer/VPS live deployment",
|
||||
"GitHub Actions after full source import"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,64 @@
|
||||
# Vendoo 1.35.0 – Modular Platform Kernel, Design-System Contracts & Security Architecture Foundation
|
||||
|
||||
## Ziel
|
||||
|
||||
Version 1.35.0 stoppt den unkontrollierten weiteren Ausbau der großen Bestandsdateien und schafft eine verbindliche Plattformarchitektur. Die bestehende Anwendung bleibt funktionsfähig und wird nicht per Big-Bang ersetzt.
|
||||
|
||||
## Implementiert
|
||||
|
||||
### Plattformkernel
|
||||
|
||||
- `app/kernel/platform-kernel.mjs`
|
||||
- geordneter Start und Stop
|
||||
- Lifecycle-Rollback bei fehlgeschlagenem Start
|
||||
- Kernelzustand im Readiness-Check
|
||||
- geordneter Kernelshutdown vor dem SQLite-Checkpoint
|
||||
|
||||
### Modulsystem
|
||||
|
||||
- zwölf validierte Bestandsmodule
|
||||
- Manifestvertrag und JSON-Schema
|
||||
- Abhängigkeitsauflösung mit Zykluserkennung
|
||||
- Capability-Prüfung
|
||||
- eindeutige Ressourcen-Ownership
|
||||
- Start-Rollback bereits gestarteter Module
|
||||
- Status `legacy-bridge` für noch nicht vollständig migrierte Bereiche
|
||||
|
||||
### Sicherheit
|
||||
|
||||
- Policy Engine mit Deny-by-default
|
||||
- Routenregistrierung nur mit Modulbesitzer und Policy
|
||||
- standardisierte Plattformfehler mit Request-ID
|
||||
- geschützte Admin-Endpunkte für Kernel-, Modul- und Theme-Vertragsstatus
|
||||
- Owner-basierter Event-Bus
|
||||
- feste Feature-Flag-Registrierung
|
||||
- isolierter Extension-Host bleibt standardmäßig deaktiviert
|
||||
|
||||
### Design-System
|
||||
|
||||
- 33 versionierte Design Tokens
|
||||
- Light, Dark und High Contrast
|
||||
- deterministische CSS- und Vertragsgenerierung
|
||||
- Kompatibilitätsbrücke zu bestehenden CSS-Variablen
|
||||
- Browser-Theme-Runtime mit Systempräferenz
|
||||
- sichere Backend-Validierung für künftige Theme-Definitionen
|
||||
- kein freies CSS, JavaScript oder externe URL-Werte
|
||||
|
||||
### Frontend-Verträge
|
||||
|
||||
- Frontend Module Registry mit `mount`/`unmount`
|
||||
- Listener-Cleanup über `AbortController`
|
||||
- Safe-DOM-Helfer auf Basis von `textContent`
|
||||
- zentraler zukünftiger API-Client mit Same-Origin-Credentials, CSRF und standardisierten Fehlern
|
||||
|
||||
## Neue interne Endpunkte
|
||||
|
||||
Nur Benutzer mit `security.manage`:
|
||||
|
||||
- `GET /api/security/platform`
|
||||
- `GET /api/security/platform/modules`
|
||||
- `GET /api/security/platform/theme-contract`
|
||||
|
||||
## Nicht behauptet
|
||||
|
||||
Version 1.35.0 ist die Foundation, nicht die vollständige Migration. `server.mjs`, `public/app.js`, `public/style.css` und `lib/db.mjs` bleiben weiterhin groß. Die Fachmodule werden ab 1.38.0 einzeln migriert. Der sichtbare Theme Manager folgt in einem eigenen Release.
|
||||
@@ -0,0 +1,27 @@
|
||||
{
|
||||
"release": "1.35.0",
|
||||
"architecture": "modular-monolith",
|
||||
"modules": 12,
|
||||
"design_tokens": 33,
|
||||
"themes": ["light", "dark", "contrast"],
|
||||
"feature_flags": 4,
|
||||
"policies": 2,
|
||||
"new_registered_routes": 3,
|
||||
"git_branch": "release/1.35.0-platform-kernel",
|
||||
"draft_pull_request": 7,
|
||||
"checks": {
|
||||
"syntax": true,
|
||||
"architecture_gate": true,
|
||||
"deployment_gate": true,
|
||||
"git_safety": true,
|
||||
"git_safety_regression": true,
|
||||
"git_staging_regression": true,
|
||||
"config_store": true,
|
||||
"installer_shell_simulation": true,
|
||||
"fresh_db_migration_blocks": 68,
|
||||
"existing_db_migration_blocks": 68,
|
||||
"existing_row_preserved": true,
|
||||
"npm_ci": false,
|
||||
"npm_ci_reason": "Native better-sqlite3 build could not finish in the network-restricted, time-limited sandbox."
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,34 @@
|
||||
# Vendoo 1.36.0 – Secure Theme Manager
|
||||
|
||||
## Ziel
|
||||
|
||||
Version 1.36.0 migriert den Theme-Bereich als erstes Fachmodul vollständig auf den Vendoo-Plattformkernel. Die sichtbare Verwaltung ist sicher, benutzerfreundlich und ohne manuelle Dateiänderungen nutzbar.
|
||||
|
||||
## Architektur
|
||||
|
||||
Das Modul `vendoo.themes` besitzt eigene Services, Repository-Funktionen, Tabellen, Policies und API-Verträge. Andere Fachbereiche bleiben zunächst als Legacy Bridges registriert.
|
||||
|
||||
## Datenmodell
|
||||
|
||||
- `theme_profiles`: administrative, validierte Theme-Profile
|
||||
- `user_theme_preferences`: persönliche Darstellung pro Benutzer
|
||||
|
||||
Die Migration ist additiv. Bestehende Vendoo-Daten werden nicht verändert oder gelöscht.
|
||||
|
||||
## Sicherheitsmodell
|
||||
|
||||
- Deny-by-default-Routen
|
||||
- Benutzer dürfen nur die eigene Präferenz ändern
|
||||
- administrative Profile und Systemstandard benötigen `settings.manage`
|
||||
- ausschließlich freigegebene Design Tokens
|
||||
- keine freie CSS-, JavaScript-, HTML-, URL- oder Dateipfad-Eingabe
|
||||
- serverseitige Wiederholungsvalidierung
|
||||
- Audit-Protokoll
|
||||
|
||||
## Design-System
|
||||
|
||||
Der Vertrag umfasst 42 typisierte Tokens und die integrierten Themes Light, Dark und High Contrast. Komponenten-Tokens steuern unter anderem Buttons, Eingaben, Karten, Dialoge, Fokusbreite und Mindestzielgröße.
|
||||
|
||||
## Kompatibilität
|
||||
|
||||
Windows lokal, Docker Desktop, NAS/Portainer und VPS bleiben unterstützt. FLUX bleibt ein getrennter Dienst. Originalbilder, Datenbank, Benutzer, Artikel, Uploads und Backups werden nicht überschrieben oder gelöscht.
|
||||
@@ -0,0 +1,50 @@
|
||||
{
|
||||
"release": "1.36.0",
|
||||
"name": "Secure Theme Manager, Accessibility & Component Token Foundation",
|
||||
"moduleCount": 12,
|
||||
"nativeModules": [
|
||||
"vendoo.themes"
|
||||
],
|
||||
"legacyBridgeCount": 11,
|
||||
"designTokenCount": 42,
|
||||
"builtinThemes": [
|
||||
"light",
|
||||
"dark",
|
||||
"contrast"
|
||||
],
|
||||
"gates": [
|
||||
"check",
|
||||
"verify:architecture",
|
||||
"verify:themes",
|
||||
"verify:deployment",
|
||||
"verify:git",
|
||||
"verify:git-regression",
|
||||
"verify:git-staging",
|
||||
"verify:config",
|
||||
"verify:installer-shell",
|
||||
"verify:db"
|
||||
],
|
||||
"runtimeTestsNotClaimed": [
|
||||
"Windows browser E2E",
|
||||
"Docker/NAS/VPS live start",
|
||||
"Caddy TLS",
|
||||
"GitHub Actions live run",
|
||||
"native better-sqlite3 install in sandbox"
|
||||
],
|
||||
"gitSafetyFilesChecked": 385,
|
||||
"releaseStagingFilesChecksummed": 384,
|
||||
"dependencyResolution": {
|
||||
"command": "npm ci --ignore-scripts",
|
||||
"packagesAdded": 151,
|
||||
"result": "passed"
|
||||
},
|
||||
"databaseVerification": {
|
||||
"freshDbExecBlocks": 68,
|
||||
"existingDbExecBlocks": 68,
|
||||
"existingRowPreserved": true,
|
||||
"themeTables": [
|
||||
"theme_profiles",
|
||||
"user_theme_preferences"
|
||||
]
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,3 @@
|
||||
# Vendoo 1.37.0 – Security, Secrets & Observability Foundation
|
||||
|
||||
Dieses Release migriert den Sicherheitsbereich als zweites natives Vendoo-Modul. Es ergänzt einen verschlüsselten Secret-Speicher, strikte Script-CSP, strukturierte Request-Telemetrie und zentrale Eingabeverträge. Bestehende Betriebsmodelle und Daten bleiben erhalten.
|
||||
@@ -0,0 +1,32 @@
|
||||
# Vendoo 1.38.0 – Auth, Users, Sessions & Settings Native Module Migration
|
||||
|
||||
## Ziel
|
||||
|
||||
Vendoo 1.38.0 migriert die kritischen Identitäts- und Administrationsbereiche aus dem gewachsenen Legacy-Kern in native Plattformmodule. Die Migration folgt weiter dem Strangler-Prinzip: vorhandene Tabellen, Benutzer, Rollen, Sitzungen und Einstellungen bleiben bestehen; die Verantwortlichkeit wird hinter klaren Modulverträgen neu geordnet.
|
||||
|
||||
## Native Module
|
||||
|
||||
- `vendoo.auth`: Setup, Login, Einladungen, Invite-Annahme und Logout
|
||||
- `vendoo.users`: eigenes Profil, Benutzerverwaltung, Rollen, Passwort-Reset und Login-Historie
|
||||
- `vendoo.sessions`: eigene und administrative Sitzungsverwaltung, Revocation und Cleanup
|
||||
- `vendoo.settings`: Anwendungseinstellungen, SMTP-Konfiguration und Secret-Store-Anbindung
|
||||
|
||||
Zusammen mit `vendoo.security` und `vendoo.themes` sind damit sechs von vierzehn registrierten Modulen nativ. Acht Bereiche bleiben transparente `legacy-bridge`-Module.
|
||||
|
||||
## Sicherheitsverbesserungen
|
||||
|
||||
- Deny-by-default-Routenverträge für alle neuen Identitäts- und Settings-Endpunkte
|
||||
- zentrale Schema-, Enum-, Integer- und Unknown-Field-Validierung
|
||||
- letzter aktiver Administrator kann nicht gelöscht, deaktiviert oder herabgestuft werden
|
||||
- Benutzer dürfen ausschließlich eigene Sitzungen widerrufen
|
||||
- administrative Sitzungsaktionen benötigen `sessions.manage`
|
||||
- Login-Historie benötigt `users.manage`
|
||||
- SMTP-Verwaltung benötigt `settings.manage`
|
||||
- unbekannte Settings-Felder werden abgewiesen
|
||||
- Passwort-Hashes, Secret-Klarwerte und Session-Tokens werden nicht in Listen- oder Statusantworten ausgegeben
|
||||
|
||||
## Kompatibilität
|
||||
|
||||
`lib/auth.mjs` bleibt als schmale Kompatibilitätsfassade bestehen und exportiert den neuen Identity Core. Dadurch können noch nicht migrierte Legacy-Bereiche weiterarbeiten, ohne eine zweite Identitätsimplementierung zu pflegen.
|
||||
|
||||
Es gibt keine Datenbankablösung und keine destruktive Migration. Windows, Docker Desktop, NAS/Portainer und VPS bleiben unterstützt.
|
||||
@@ -0,0 +1,38 @@
|
||||
{
|
||||
"release": "1.38.0",
|
||||
"date": "2026-07-09",
|
||||
"status": "passed_with_runtime_limitations",
|
||||
"module_counts": {
|
||||
"total": 14,
|
||||
"native": 6,
|
||||
"legacy_bridge": 8
|
||||
},
|
||||
"gates": {
|
||||
"git_safety_files": 425,
|
||||
"git_safety": true,
|
||||
"git_safety_regression": true,
|
||||
"git_staging_regression": true,
|
||||
"syntax": true,
|
||||
"architecture": true,
|
||||
"identity_settings": true,
|
||||
"theme_manager": true,
|
||||
"security_foundation": true,
|
||||
"deployment": true,
|
||||
"config_store": true,
|
||||
"installer_shell": true,
|
||||
"database_fresh_exec_blocks": 68,
|
||||
"database_existing_exec_blocks": 68,
|
||||
"existing_row_preserved": true,
|
||||
"foreign_session_revoke_blocked": true,
|
||||
"own_session_revoke_succeeded": true,
|
||||
"npm_lock_resolution_packages": 151,
|
||||
"compose_yaml": true,
|
||||
"powershell_utf8_bom": true
|
||||
},
|
||||
"runtime_limitations": [
|
||||
"Windows/PowerShell and browser end-to-end not available in sandbox",
|
||||
"Docker, NAS, VPS, Caddy and TLS live startup not available in sandbox",
|
||||
"Native better-sqlite3 install could not download GitHub prebuilds or Node headers because sandbox network resolution failed",
|
||||
"GitHub Actions live run requires the complete local source push"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,15 @@
|
||||
# Vendoo 1.39.0 – Listings, Inventory & Media Native Module Migration
|
||||
|
||||
Version 1.39.0 überführt die zentralen Katalog- und Medienrouten in native Module. Bestehende API-Verträge, Tabellen und Benutzerabläufe bleiben kompatibel.
|
||||
|
||||
## Kernumfang
|
||||
|
||||
- native Listings-, Inventory- und Media-Module
|
||||
- Deny-by-default-Policies
|
||||
- Artikel-Allowlist und HTML-Sanitizing
|
||||
- Bearbeitungssperren
|
||||
- sichere Papierkorbgrenzen
|
||||
- Inventory-Bulk-Limit
|
||||
- Medienpfad- und Referenzschutz
|
||||
- Dependency Injection für Repositories
|
||||
- verpflichtendes Catalog-/Media-Gate in CI und Release
|
||||
@@ -0,0 +1,28 @@
|
||||
{
|
||||
"release": "1.39.0",
|
||||
"modules": {
|
||||
"total": 15,
|
||||
"native": 9,
|
||||
"legacy_bridge": 6
|
||||
},
|
||||
"gates": [
|
||||
"git-safety",
|
||||
"git-staging",
|
||||
"syntax",
|
||||
"architecture",
|
||||
"themes",
|
||||
"security",
|
||||
"identity-settings",
|
||||
"catalog-media",
|
||||
"deployment",
|
||||
"config-store",
|
||||
"installer-shell",
|
||||
"db-migrations"
|
||||
],
|
||||
"runtime_tests_not_claimed": [
|
||||
"windows-browser-e2e",
|
||||
"native-better-sqlite3",
|
||||
"docker-nas-vps-live",
|
||||
"github-actions-before-push"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,5 @@
|
||||
# Vendoo 1.40.0 – Secure Module Manager
|
||||
|
||||
Version 1.40.0 führt den administrativen Modulmanager und native Lebenszyklen für Publishing, AI, FLUX Studio und Quality Center ein.
|
||||
|
||||
Die bestehenden Funktionen und API-Pfade bleiben kompatibel. Kernmodule sind geschützt. Optionale Vendoo-Module lassen sich kontrolliert deaktivieren. Deklarative Fremdmodule können als geprüfte `.vmod`-Pakete installiert, exportiert und entfernt werden. Ausführbare Fremdmodule bleiben bis zur Einführung des isolierten Extension-Hosts in Quarantäne.
|
||||
@@ -0,0 +1,18 @@
|
||||
{
|
||||
"release": "1.40.0",
|
||||
"module_count": 16,
|
||||
"native_modules": 14,
|
||||
"legacy_bridges": 2,
|
||||
"external_execution": "quarantined-until-isolated-host",
|
||||
"required_gates": [
|
||||
"verify:git",
|
||||
"verify:architecture",
|
||||
"verify:themes",
|
||||
"verify:security",
|
||||
"verify:identity",
|
||||
"verify:catalog",
|
||||
"verify:modules",
|
||||
"verify:deployment",
|
||||
"verify:db"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,17 @@
|
||||
# Vendoo 1.40.2 – Capability Graph Contract Hotfix
|
||||
|
||||
## Ursache
|
||||
|
||||
`vendoo.module-manager` konsumierte `settings.configuration`. Das native Settings-Modul stellte jedoch nur `settings.application` und `settings.smtp` bereit. Der Plattformkernel brach deshalb vor dem Start der Module mit `MODULE_CAPABILITY_MISSING` ab.
|
||||
|
||||
## Korrektur
|
||||
|
||||
- `vendoo.settings` stellt zusätzlich `settings.configuration` bereit.
|
||||
- `ModuleRegistry.validateGraph()` validiert den vollständigen aktivierten Modulgraph ohne Ausführung der Lifecycles.
|
||||
- Das neue Gate `npm run verify:capabilities` prüft alle 16 Module, Abhängigkeiten, Startreihenfolgen und 35 Capabilities.
|
||||
- CI, Release, Architektur- und Deployment-Gates führen die Gesamtgraphprüfung verpflichtend aus.
|
||||
- Der FLUX-Worker- und ESM-Export-Hotfix aus 1.40.1 bleibt enthalten.
|
||||
|
||||
## Daten
|
||||
|
||||
Keine Datenbankmigration, kein Reset und keine Änderung an Benutzer-, Artikel-, Medien-, Modul- oder Secret-Daten.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Vendoo 1.41.0 – Coolify Production Deployment & Controlled Web Updates
|
||||
|
||||
## Ziel
|
||||
|
||||
Vendoo 1.41.0 bereitet den reproduzierbaren Produktionsbetrieb unter `https://vendoo.flatlined.de` vor. GitHub ist die Quell- und Releasequelle, Coolify baut oder zieht den Container und Vendoo fordert spätere Deployments ausschließlich über eine kontrollierte, verschlüsselte Schnittstelle an.
|
||||
|
||||
## Architektur
|
||||
|
||||
```text
|
||||
Release-Branch → Pull Request → GitHub Actions → main → GitHub Release/GHCR
|
||||
│
|
||||
▼
|
||||
Coolify Deployment
|
||||
│
|
||||
▼
|
||||
https://vendoo.flatlined.de
|
||||
│
|
||||
▼
|
||||
Volume /app/data
|
||||
```
|
||||
|
||||
## Neu
|
||||
|
||||
- geschütztes natives Modul `vendoo.deployments`
|
||||
- 17 Module, 15 nativ und 2 Legacy Bridges
|
||||
- 38 aufgelöste Capabilities
|
||||
- Coolify Webhook- und API-Modus
|
||||
- verschlüsselte Coolify-Zugangsdaten
|
||||
- Vorab-Backup und Bestätigung `DEPLOY`
|
||||
- Dockerfile-Produktion ohne eigenen Caddy-Container
|
||||
- ein persistenter Datenbereich `/app/data`
|
||||
- FLUX Studio beim ersten Start deaktiviert
|
||||
- GHCR-Images mit Semver-, `stable`- und `latest`-Tags
|
||||
- vollständige GitHub-, Merge-, Release- und Coolify-Anleitungen
|
||||
|
||||
## Unveränderlicher Container
|
||||
|
||||
Vendoo führt im Container kein `git pull`, kein `npm install`, kein `docker compose` und keine Docker-Socket-Kommandos aus. Ein Updateauftrag wird nach erfolgreichem Backup an Coolify delegiert. Coolify erzeugt einen neuen Container aus dem freigegebenen GitHub-Stand beziehungsweise dem veröffentlichten Image.
|
||||
|
||||
## Persistente Daten
|
||||
|
||||
Das Coolify-Volume `/app/data` enthält Datenbank, Uploads, Backups, Operations-Daten, Konfiguration, Secret Store, Master-Key, installierte Module, Modulzustand und Logs. Das Volume darf bei Updates nicht gelöscht oder neu angelegt werden.
|
||||
|
||||
## FLUX Studio
|
||||
|
||||
Beim ersten Produktionsstart gelten:
|
||||
|
||||
```env
|
||||
VENDOO_INITIAL_DISABLED_MODULES=vendoo.flux-studio
|
||||
LOCAL_IMAGE_ENABLED=false
|
||||
```
|
||||
|
||||
Der Initialwert gilt nur, solange noch keine persistente Modulentscheidung existiert. Eine spätere Aktivierung im Modulmanager bleibt erhalten.
|
||||
|
||||
## Updateablauf
|
||||
|
||||
1. vollständigen Quellstand auf Release-Branch übertragen
|
||||
2. GitHub Actions prüfen
|
||||
3. Pull Request nach `main` mergen
|
||||
4. GitHub Release veröffentlichen
|
||||
5. optional GHCR-Image kontrollieren
|
||||
6. im Vendoo Update Center Version prüfen
|
||||
7. Coolify-Deployment mit `DEPLOY` bestätigen
|
||||
8. Backup und Deploymentstatus kontrollieren
|
||||
9. `/readyz`, Login und Kernfunktionen prüfen
|
||||
|
||||
## Ausführliche Dokumente
|
||||
|
||||
- `docs/GITHUB_MERGE_RELEASE_1_41_0.md`
|
||||
- `docs/COOLIFY_PRODUCTION_1_41_0.md`
|
||||
- `docs/WEB_UPDATE_CENTER_1_41_0.md`
|
||||
- `docs/ABNAHMEBERICHT_1_41_0.md`
|
||||
@@ -0,0 +1,26 @@
|
||||
{
|
||||
"release": "1.41.0",
|
||||
"name": "Coolify Production Deployment & Controlled Web Updates",
|
||||
"status": "passed_with_live_deployment_pending",
|
||||
"modules": 17,
|
||||
"native_modules": 15,
|
||||
"legacy_bridges": 2,
|
||||
"capabilities": 38,
|
||||
"database_migration_blocks_fresh": 68,
|
||||
"database_migration_blocks_existing": 68,
|
||||
"existing_row_preserved": true,
|
||||
"npm_packages_resolved": 151,
|
||||
"flux_initially_disabled": true,
|
||||
"docker_socket_access": false,
|
||||
"coolify_provider": true,
|
||||
"pre_deploy_backup": true,
|
||||
"github_pull_request": 16,
|
||||
"live_checks_pending": [
|
||||
"github_actions_docker_build",
|
||||
"github_merge_to_main",
|
||||
"github_release_v1.41.0",
|
||||
"ghcr_multi_arch_publish",
|
||||
"coolify_public_deployment",
|
||||
"dns_tls_and_browser_e2e"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,18 @@
|
||||
# Vendoo 1.41.1 – CI Source Root & Archive Exclusion Hotfix
|
||||
|
||||
## Ursache
|
||||
|
||||
Der GitHub-Workflow prüfte mit dem ESM-Vertragsgate den gesamten Repositorybaum. Dadurch wurde auch ein historischer Stand unter `Archiv/Vendoo_Feature_1_41_0_.../vendoo/server.mjs` wie produktiver Quellcode behandelt. Dieser Altstand importierte Dateien, die innerhalb des archivierten Pakets nicht vorhanden waren. Die produktiven Dateien im echten Vendoo-Root waren dagegen vorhanden.
|
||||
|
||||
## Korrektur
|
||||
|
||||
- Produktive ESM-Prüfung ist auf `server.mjs`, `bootstrap.mjs`, `app/`, `lib/`, `public/`, `scripts/` und `tools/` begrenzt.
|
||||
- `Archiv/`, `archive/` und `archives/` werden von Git-Staging und Release-Staging ausgeschlossen.
|
||||
- Bereits auf einem Release-Branch versionierte Archivdateien werden beim nächsten Deploy-Assistent-Lauf aus dem Branch entfernt, weil das Staging-Ziel vorher bereinigt wird.
|
||||
- Die produktiven Dateien `app/modules/listings/routes.mjs`, `app/modules/inventory/index.mjs`, `repository.mjs` und `routes.mjs` sind Pflichtdateien.
|
||||
- Ein Regressionstest erzeugt absichtlich einen defekten Archivstand und bestätigt, dass dieser ignoriert wird.
|
||||
- Derselbe Test entfernt anschließend eine echte Source-Datei und bestätigt, dass CI weiterhin fehlschlägt.
|
||||
|
||||
## Daten
|
||||
|
||||
Keine Datenbankmigration, kein Reset und keine Veränderung von Benutzerdaten, Uploads, Secrets, Modulen oder Coolify-Konfiguration.
|
||||
@@ -0,0 +1,14 @@
|
||||
# Vendoo 1.41.2 – Git Ignore Boundary & Module Tracking Hotfix
|
||||
|
||||
## Ursache
|
||||
|
||||
Die Regel `modules/` in `.gitignore` ignorierte auch `app/modules/`. Entsprechend konnte der Deploy-Assistent Dateien kopieren, die `git add --all` anschließend nicht aufnahm. Die Regel `sessions/` hatte dasselbe Risiko für `app/modules/sessions/`.
|
||||
|
||||
## Fix
|
||||
|
||||
- Runtimeordner sind mit führendem `/` auf den Projektroot begrenzt.
|
||||
- Ein echtes temporäres Git-Repository prüft Ignore- und Trackingverhalten.
|
||||
- Der Deploy-Assistent prüft alle Pflichtdateien nach `git add --all` mit `git ls-files`.
|
||||
- CI führt das neue Gate vor Syntax- und Source-Root-Prüfungen aus.
|
||||
|
||||
Keine Datenbankmigration.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Roadmap ab Vendoo 1.38.0
|
||||
|
||||
## Aktueller Modulstand
|
||||
|
||||
- 14 Module insgesamt
|
||||
- 6 nativ: Auth, Users, Sessions, Settings, Security, Themes
|
||||
- 8 Legacy Bridges: System, Media, Listings, AI, FLUX Studio, Quality, Publishing, Operations
|
||||
|
||||
## Nächster Slice
|
||||
|
||||
**Vendoo 1.39.0 – Listings, Inventory & Media Native Module Migration**
|
||||
|
||||
Ziele:
|
||||
|
||||
- Artikel-, Lager- und Medienlogik aus `server.mjs`, `lib/db.mjs` und `public/app.js` lösen
|
||||
- eigene Repositories, Services, Routen und Frontend-Lebenszyklen
|
||||
- zentrale Upload- und Medien-Pipeline
|
||||
- Besitz- und Berechtigungsverträge für Artikel und Bilder
|
||||
- nicht destruktive Migration ohne Verlust vorhandener Artikel oder Uploads
|
||||
|
||||
Danach folgen Publishing/Adapter sowie AI/FLUX als getrennte native Module.
|
||||
@@ -0,0 +1,14 @@
|
||||
# Roadmap ab Vendoo 1.39.0
|
||||
|
||||
## Aktueller Modulstand
|
||||
|
||||
- 9 nativ: Auth, Users, Sessions, Settings, Security, Themes, Media, Listings, Inventory
|
||||
- 6 Legacy Bridges: System, AI, FLUX Studio, Quality, Publishing, Operations
|
||||
|
||||
## Nächste Schritte
|
||||
|
||||
1. **1.40.0:** Publishing, AI und FLUX als native Module; Adaptergrenzen und Jobverträge.
|
||||
2. **1.41.0:** Quality und Operations nativ; Backup-, Update- und Diagnoseverträge.
|
||||
3. **1.42.0:** Frontend-Zerlegung von `public/app.js` in fachliche ES-Module und tokenisierte Komponenten.
|
||||
4. **1.43.0:** isolierter Extension Host mit signierten Manifesten und Capability Tokens.
|
||||
5. **1.44.0:** Produktivitäts-Härtung, E2E-, Last-, Restore- und Upgrade-Matrix.
|
||||
@@ -0,0 +1,14 @@
|
||||
# Roadmap ab Vendoo 1.40.0
|
||||
|
||||
## Nächster Architektur-Slice
|
||||
|
||||
**Vendoo 1.41.0 – Isolated Extension Host, Signed Module Registry & Permissions UI**
|
||||
|
||||
- separater Extension-Host-Prozess oder Container
|
||||
- Capability-Tokens mit minimalen Rechten
|
||||
- vertrauenswürdige Signaturschlüssel und Widerrufsliste
|
||||
- Modulberechtigungen vor Installation anzeigen und bestätigen
|
||||
- Update- und Rollback-Ablauf pro Fremdmodul
|
||||
- Healthchecks, Ressourcenlimits und Netzwerk-Allowlist
|
||||
|
||||
Bis dahin führt Vendoo keinen ausführbaren Fremdcode aus `.vmod`-Paketen aus.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Slice 02 – Listings / Historie Acceptance
|
||||
|
||||
## Abnahmeziele
|
||||
|
||||
- [x] freigegebene Vendoo-Designsprache übernommen
|
||||
- [x] bestehende Listings-API unverändert weiterverwendet
|
||||
- [x] Suche, Plattform-, Status- und Datumsfilter erhalten
|
||||
- [x] Zeitraumauswahl ergänzt
|
||||
- [x] CSV- und JSON-Export erhalten
|
||||
- [x] Einzel- und Seitenauswahl umgesetzt
|
||||
- [x] Batch Status, Preis, Duplizieren, Etiketten, Publish und Löschen umgesetzt
|
||||
- [x] Inline-Statusänderung pro Listing erhalten
|
||||
- [x] Detailansicht weiterhin erreichbar
|
||||
- [x] Pagination mit direkter Seitenauswahl umgesetzt
|
||||
- [x] Spaltenkonfiguration lokal gespeichert
|
||||
- [x] Dark-Mode-Tokens verwendet
|
||||
- [x] keine hardcodierten produktiven Secrets enthalten
|
||||
|
||||
## Technische Prüfungen
|
||||
|
||||
- `node --check public/app.js`
|
||||
- `node --check server.mjs`
|
||||
- `node --check lib/db.mjs`
|
||||
- keine doppelten HTML-IDs
|
||||
- ausgeglichene CSS-Klammerstruktur
|
||||
|
||||
## Runtime-Hinweis
|
||||
|
||||
Ein vollständiger Runtime-Test benötigt die plattformspezifische Installation von `better-sqlite3`. Das Paket enthält bewusst kein `node_modules`; Installation erfolgt über den gehärteten Installer beziehungsweise `npm ci`.
|
||||
@@ -0,0 +1,28 @@
|
||||
# Slice 05 – Abnahme Publish-Center
|
||||
|
||||
## Funktionsumfang
|
||||
|
||||
- [x] Smart Copy vollständig innerhalb Vendoo
|
||||
- [x] direkte Etsy-/eBay-Veröffentlichung mit Integrationsstatus
|
||||
- [x] Listing-Daten vor der Veröffentlichung inline bearbeitbar
|
||||
- [x] eBay Queue ohne separates Modal steuerbar
|
||||
- [x] Fehler, Wiederholungen und Queue-Status sichtbar
|
||||
- [x] geplante Veröffentlichungen inline verwaltbar
|
||||
- [x] Batch-Auswahl aus Listings wird übernommen
|
||||
- [x] Fotos werden vollständig ohne Beschnitt dargestellt
|
||||
- [x] responsive Layouts für Desktop, Tablet und Mobile
|
||||
- [x] Dark Mode ausschließlich über zentrale CSS-Variablen
|
||||
|
||||
## Technische Prüfungen
|
||||
|
||||
- [x] `node --check server.mjs`
|
||||
- [x] `node --check lib/db.mjs`
|
||||
- [x] `node --check public/app.js`
|
||||
- [x] keine doppelten HTML-IDs
|
||||
- [x] ausgeglichene CSS-Klammerstruktur
|
||||
- [x] keine `.env`, Datenbank, Uploads oder `node_modules` im Paket
|
||||
- [x] bestehende API-Routen, Authentifizierung und CSRF-Logik beibehalten
|
||||
|
||||
## Installation
|
||||
|
||||
Als Update über `setup.bat` → **3 Update** installieren. Danach Browser mit `Strg + F5` neu laden.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Slice 06 – Abnahme
|
||||
|
||||
## Funktionsabnahme
|
||||
|
||||
- [x] Studio Flow öffnet den sichtbaren Listing-Editor.
|
||||
- [x] gespeicherte Listings können vollständig bearbeitet werden.
|
||||
- [x] Fotos können ergänzt, entfernt, sortiert und als Cover gesetzt werden.
|
||||
- [x] der vorhandene Fotoeditor funktioniert im Generator und im Listing-Editor.
|
||||
- [x] WYSIWYG-Änderungen erscheinen unmittelbar im HTML-Code.
|
||||
- [x] HTML-Codeänderungen werden in den WYSIWYG-Editor zurückgeführt.
|
||||
- [x] Generator und Listing-Editor rendern eine separate Plattformvorschau.
|
||||
- [x] Rich-Text-HTML wird dauerhaft in `description_html` gespeichert.
|
||||
- [x] Klartext bleibt in `description` als Fallback erhalten.
|
||||
- [x] Plattformvorschauen laufen in sandboxed iframes.
|
||||
|
||||
## Technische Abnahme
|
||||
|
||||
- [x] DB-Migration für `description_html` im `MIGRATIONS`-Array.
|
||||
- [x] `photos` und `tags` werden bei Updates als JSON gespeichert.
|
||||
- [x] Listing-Updates verwenden eine feste Feld-Allowlist.
|
||||
- [x] Client- und Server-Sanitizing für Rich-Text-HTML.
|
||||
- [x] JavaScript-/ESM-Syntaxprüfung bestanden.
|
||||
- [x] keine doppelten statischen HTML-IDs.
|
||||
- [x] CSS-Klammerstruktur vollständig.
|
||||
- [x] keine `.env`, Datenbanken, Uploads oder `node_modules` im Paket.
|
||||
@@ -0,0 +1,36 @@
|
||||
# Slice 07 – Cross-Browser Extensions, Responsive UI & Mobile Upload
|
||||
|
||||
## Browser-Erweiterungen
|
||||
|
||||
- Chrome: `extensions/chrome`
|
||||
- Edge: `extensions/edge`
|
||||
- Firefox: `extensions/firefox`
|
||||
- neues Vendoo-Link-Icon in 16/32/48/128 px
|
||||
- neues Popup nach freigegebenem Mockup
|
||||
- neuer Vendoo Assistant mit produktzentrierter Detailansicht und Auto-Fill-Flow
|
||||
|
||||
## HTML-/Plattformvorschau
|
||||
|
||||
Im Generator und Listing-Editor ist HTML nicht mehr als dauerhaft zweite Spalte sichtbar. Innerhalb der Plattformvorschau kann zwischen **Plattformvorschau** und **HTML-Code** umgeschaltet werden. WYSIWYG und HTML bleiben bidirektional synchronisiert.
|
||||
|
||||
## Responsive Layout
|
||||
|
||||
Abnahmepunkte:
|
||||
|
||||
- Desktop ab 1440 px
|
||||
- Notebook 1180–1439 px
|
||||
- iPad Querformat 1024 px
|
||||
- Tablet Hochformat 768 px
|
||||
- Smartphone 360–560 px
|
||||
|
||||
Navigation, Generator, Listing-Editor, Studio Flow, Tabellen, Modale und Kontextbereiche werden je Breakpoint neu priorisiert.
|
||||
|
||||
## Mobiler Foto-Upload
|
||||
|
||||
1. Nutzer erzeugt in Generator oder Listing-Editor einen QR-Code.
|
||||
2. Vendoo erstellt ein kryptografisch zufälliges, gehasht gespeichertes Upload-Token.
|
||||
3. Der Link ist 20 Minuten gültig und auf maximal zehn Bilder begrenzt.
|
||||
4. Smartphone lädt Bilder über eine eigenständige responsive Upload-Seite hoch.
|
||||
5. Desktop pollt die Sitzung und übernimmt neue Bilder automatisch.
|
||||
|
||||
`PUBLIC_BASE_URL` oder eine erreichbare LAN-/HTTPS-Adresse ist erforderlich, wenn der QR-Code von einem anderen Gerät geöffnet wird.
|
||||
@@ -0,0 +1,33 @@
|
||||
# Slice 08 – Extension Auto-Fill & UX
|
||||
|
||||
## Ziel
|
||||
|
||||
Die Vinted-Erweiterung soll kompakt, hochwertig und sicher bedienbar sein. Das bloße Ausfüllen eines Formulars darf niemals automatisch einen Entwurf erzeugen oder eine Veröffentlichung auslösen.
|
||||
|
||||
## Verbindliches Aktionsmodell
|
||||
|
||||
1. **Nur ausfüllen**
|
||||
- trägt Titel, Beschreibung, Preis, Tags und bestmöglich weitere Attribute ein
|
||||
- wählt die Kategorie, sofern möglich
|
||||
- speichert keinen Entwurf
|
||||
- veröffentlicht nicht
|
||||
- setzt keinen Publish-Status in Vendoo
|
||||
|
||||
2. **Daten + Bilder ausfüllen**
|
||||
- überträgt zusätzlich die Produktbilder
|
||||
- speichert keinen Entwurf
|
||||
- veröffentlicht nicht
|
||||
|
||||
3. **Als Entwurf** und **Veröffentlichen**
|
||||
- sind getrennte, explizite Abschlussaktionen
|
||||
- befinden sich im Detailbereich unter einer aufklappbaren Sicherheitssektion
|
||||
|
||||
## Browser
|
||||
|
||||
Identische UI- und Funktionsbasis unter:
|
||||
|
||||
- `extensions/chrome`
|
||||
- `extensions/edge`
|
||||
- `extensions/firefox`
|
||||
|
||||
Version: `1.4.0`
|
||||
@@ -0,0 +1,17 @@
|
||||
# Slice 11 – Dashboard-First & Responsive Hotfix
|
||||
|
||||
## Umfang
|
||||
|
||||
- Dashboard als erster Navigationspunkt und Standardansicht
|
||||
- fließende KPI-Kacheln mit Auto-Fit
|
||||
- responsive Sparklines und Diagramme
|
||||
- ResizeObserver für Dashboard-Visualisierungen
|
||||
- vollständige Produktbild-Darstellung im Studio Flow
|
||||
- automatische Kartenverteilung für Desktop, Tablet und Mobile
|
||||
|
||||
## Abnahme
|
||||
|
||||
- keine Text-/Diagrammüberlagerung in KPI-Karten
|
||||
- keine abgeschnittenen Bilder in „Bereit für den nächsten Schritt“
|
||||
- Dashboard öffnet nach dem Login zuerst
|
||||
- Diagramme reagieren auf Fenster- und Sidebar-Breitenänderungen
|
||||
@@ -0,0 +1,34 @@
|
||||
# Slice 22.1 – Setup-integrated FLUX recovery
|
||||
|
||||
## Confirmed incident
|
||||
|
||||
The 7-Zip process completed successfully with `Everything is Ok`, 54,878 files
|
||||
and about 4,038 MB extracted. Windows PowerShell 5.1 nevertheless exposed an
|
||||
empty `Process.ExitCode`, which the previous installer treated as a non-zero
|
||||
failure.
|
||||
|
||||
## Recovery contract
|
||||
|
||||
The setup startup recovery activates only when all of these conditions match:
|
||||
|
||||
1. `install-state.json` is `failed` and `can_resume=true`.
|
||||
2. The stored message contains the empty 7-Zip exit-code failure and
|
||||
`Everything is Ok`.
|
||||
3. The 7-Zip stderr log is empty.
|
||||
4. The stdout log contains the success marker.
|
||||
5. The extracted portable tree contains both `ComfyUI\main.py` and
|
||||
`python_embeded\python.exe`.
|
||||
6. No matching installer or 7-Zip process is still active.
|
||||
7. The final ComfyUI target is not already installed.
|
||||
|
||||
The user starts only `setup.bat`. Setup then offers to continue automatically.
|
||||
The complete extraction is reused; no repeat extraction or project reset occurs.
|
||||
|
||||
## Required Windows acceptance
|
||||
|
||||
- Run the provided one-click updater.
|
||||
- Let the updater parser-check and back up the three affected files.
|
||||
- Allow the newly launched `setup.bat` to continue the detected installation.
|
||||
- Confirm the log contains `Vollständiger temporärer ComfyUI-Entpackstand wird wiederverwendet`.
|
||||
- Confirm ComfyUI, Python, workflow, model and start/stop scripts are present.
|
||||
- Confirm `http://127.0.0.1:8188/system_stats` is reachable after startup.
|
||||
@@ -0,0 +1,23 @@
|
||||
# Vendoo Slice 22.2 – Download Recovery 1.14.4
|
||||
|
||||
## Bestätigter Fehler
|
||||
|
||||
Der asynchrone BITS-Aufruf konnte unter Windows PowerShell 5.1 ein leeres Jobobjekt liefern. Dadurch wurde `Get-BitsTransfer` mit einer leeren Job-ID aufgerufen. Der anschließende `Invoke-WebRequest`-Fallback zeigte bei großen Dateien nur die PowerShell-Standardmeldung „Webanforderung wird geschrieben“ und bot keine verlässliche Fortschritts- oder Wiederaufnahmefunktion.
|
||||
|
||||
## Korrektur
|
||||
|
||||
- BITS und `Invoke-WebRequest` wurden für große Binärdownloads ersetzt.
|
||||
- Neuer .NET-Streaming-Downloader mit HTTP-Range-Wiederaufnahme.
|
||||
- Vorhandene `.part`-Dateien bleiben erhalten.
|
||||
- Fortschritt mit Prozent, MB, Gesamtgröße, MB/s und Restzeit.
|
||||
- Statusdatei wird alle zwei Sekunden aktualisiert.
|
||||
- Konsolen-Heartbeat alle zehn Sekunden.
|
||||
- Bis zu fünf automatische Wiederholungen nach Netzwerkunterbrechungen.
|
||||
- `setup.bat` erkennt einen unterbrochenen Modell-Download und setzt ihn ohne Menüeingabe fort.
|
||||
- Der Ein-Klick-Updater beendet den alten Installerprozess, entfernt veraltete BITS-Jobs, sichert die Altdateien und startet Vendoo automatisch neu.
|
||||
|
||||
## Geänderte Dateien
|
||||
|
||||
- `setup.bat`
|
||||
- `setup.ps1`
|
||||
- `scripts/install-local-flux.ps1`
|
||||
@@ -0,0 +1,22 @@
|
||||
# Vendoo Slice 22.3 – PowerShell 5.1 Parser Fix 1.14.5
|
||||
|
||||
## Fehlerbild
|
||||
|
||||
Windows PowerShell 5.1 meldete beim Start von `scripts/install-local-flux.ps1`:
|
||||
|
||||
```text
|
||||
InvalidVariableReferenceWithDrive
|
||||
Ungültiger Variablenverweis. Nach ":" folgte kein Zeichen ...
|
||||
```
|
||||
|
||||
## Ursache
|
||||
|
||||
Innerhalb zweier interpolierter Zeichenfolgen stand `$Label:`. PowerShell 5.1 interpretiert den Doppelpunkt direkt nach einem Variablennamen als mögliche Scope-/Laufwerksangabe.
|
||||
|
||||
## Korrektur
|
||||
|
||||
Beide Vorkommen wurden auf `${Label}:` geändert. Damit ist der Variablenname eindeutig begrenzt.
|
||||
|
||||
## Updateweg
|
||||
|
||||
Den vollständigen ZIP-Inhalt über den bestehenden Vendoo-Ordner kopieren und gleichnamige Dateien ersetzen. Den Zielordner nicht vorher löschen. Anschließend `setup.bat` doppelklicken. Vorhandene `.part`-Downloads bleiben erhalten und werden fortgesetzt.
|
||||
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"setup.ps1": "bf5fc9f0a56e7d01f16419427f4bd3af1043c9b67e091fe595542ca49bbc164b",
|
||||
"scripts/install-local-flux.ps1": "67488baffc35a5b6af4b3379468226a202611fff1ee63358992014a5e4de80fd",
|
||||
"CHANGELOG.md": "8292be2828a0d1340318ba19b40dec55b8eeccf96171b903066a6fc9ac15e674",
|
||||
"docs/SLICE_22_3_POWERSHELL_51_PARSER_FIX.md": "95e1d560378120d7ccb0f363720ba832505631aa65616abd4df01baba5ecc269"
|
||||
}
|
||||
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"scripts/install-local-flux.ps1": "8ded6e1e3a311f36eb1f5be5165ee3b56b88b05b42b29826ce218cdc3b2ee848",
|
||||
"lib/ai-local-images.mjs": "1439c483d7562a4fb16197edb2221e93c34ce1814e261ef1fe8c6fc26b9e767c",
|
||||
"local-ai/workflows/vendoo_flux_schnell_api.json": "5f220a2dca02cc0764f6d0157677611b26c88860b48367eb661b6e47a1b92265",
|
||||
"package.json": "ab72cdee8fbd1e4d8e743a19c90d2343beb7c960dc4a8642f2a94fc5ae4a3abb",
|
||||
"CHANGELOG.md": "7c9e9de1e943052a910a6dd64e7dc56c427908a6e5542bd87cf00c5f90586f21",
|
||||
"docs/SLICE_22_4_UTF8_BOM_FIX.md": "d14c938c6c9397290f654406d4b995b63db0f22586e78fc97fb5fef575748807",
|
||||
"docs/SLICE_22_4_VERIFICATION.json": "f00c325ec3c879b47908dd5410cc943febb923200e9b9bd7d18197b1570a26fe"
|
||||
}
|
||||
@@ -0,0 +1,26 @@
|
||||
# Slice 22.4 – UTF-8-BOM-Fix für lokalen FLUX-Workflow
|
||||
|
||||
## Reale Fehlerursache
|
||||
|
||||
Windows PowerShell 5.1 schreibt bei `Set-Content -Encoding utf8` standardmäßig
|
||||
ein UTF-8-BOM. Dadurch begann die Workflow-Datei unsichtbar mit `U+FEFF` vor
|
||||
dem eigentlichen `{`.
|
||||
|
||||
Node.js `JSON.parse()` meldete deshalb:
|
||||
|
||||
```text
|
||||
Unexpected token '', "{ ..." is not valid JSON
|
||||
```
|
||||
|
||||
## Korrektur
|
||||
|
||||
- zentrale `Write-Utf8NoBom`-Funktion im FLUX-Installer
|
||||
- Workflow-JSON und Installationsstatus werden ohne BOM geschrieben
|
||||
- Laufzeit entfernt defensiv ein vorhandenes BOM vor `JSON.parse()`
|
||||
- mitgelieferte Workflow-Datei ist BOM-frei
|
||||
|
||||
## Benutzerablauf
|
||||
|
||||
Vollständigen ZIP-Stand entpacken und über den bestehenden Vendoo-Ordner
|
||||
kopieren. Gleichnamige Dateien ersetzen, den Zielordner nicht löschen.
|
||||
Danach `setup.bat` starten.
|
||||
@@ -0,0 +1,27 @@
|
||||
{
|
||||
"version": "1.14.6",
|
||||
"json_files_validated": 10,
|
||||
"json_files_with_bom": [],
|
||||
"node_syntax_checks": {
|
||||
"lib/ai-local-images.mjs": {
|
||||
"returncode": 0,
|
||||
"stderr": ""
|
||||
},
|
||||
"server.mjs": {
|
||||
"returncode": 0,
|
||||
"stderr": ""
|
||||
},
|
||||
"public/app.js": {
|
||||
"returncode": 0,
|
||||
"stderr": ""
|
||||
}
|
||||
},
|
||||
"changed_files": [
|
||||
"scripts/install-local-flux.ps1",
|
||||
"lib/ai-local-images.mjs",
|
||||
"local-ai/workflows/vendoo_flux_schnell_api.json",
|
||||
"package.json",
|
||||
"CHANGELOG.md",
|
||||
"docs/SLICE_22_4_UTF8_BOM_FIX.md"
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,52 @@
|
||||
# Slice 23 – FLUX Product Reference, Live Progress & Settings Command Center
|
||||
|
||||
## Reale Ausgangsfehler
|
||||
|
||||
1. Der lokale ComfyUI-Workflow war Text-to-Image. `__SOURCE_IMAGE__` wurde ersetzt,
|
||||
aber von keinem Workflow-Knoten verwendet. Das Produktfoto hatte deshalb keinen
|
||||
technischen Einfluss auf das Ergebnis.
|
||||
2. AI-Bildjobs setzten beim Start einmal `progress = 10` und erst am Ende `100`.
|
||||
3. Eine alte oder nicht lesbare `install-state.json` konnte `unknown` liefern,
|
||||
obwohl alle realen Installationsdateien vorhanden waren.
|
||||
4. Die Einstellungen bestanden aus einer langen, ungruppierten Liste.
|
||||
|
||||
## Umsetzung
|
||||
|
||||
### Produktreferenz
|
||||
|
||||
- Upload des ersten Produktfotos über ComfyUI `/upload/image`
|
||||
- dynamische Workflow-Erweiterung mit `LoadImage`, `ImageScale` und `VAEEncode`
|
||||
- KSampler nutzt den referenzbasierten Latent-Input
|
||||
- modusabhängige Denoise-Stärke plus einstellbare Referenztreue
|
||||
- 768 × 768 als schneller Standard; 1024 × 1024 als optionale Qualitätsstufe
|
||||
- verstärkte Prompt-Regeln für Farbe, Kapuze, Reißverschluss, Taschen, Logos,
|
||||
Drucke, Nähte und sichtbare Gebrauchsspuren
|
||||
|
||||
### Fortschritt
|
||||
|
||||
- additive DB-Migration `ai_model_jobs.progress_message`
|
||||
- Fortschrittsmeldungen für Vorprüfung, Providerwahl, Referenzupload,
|
||||
ComfyUI-Rendering, Sicherheitsprüfung und Speicherung
|
||||
- sichtbare Fortschrittskarte im Generator und Listing-Editor
|
||||
|
||||
### Status und Administration
|
||||
|
||||
- BOM-sicheres Lesen der Installationsstatusdatei
|
||||
- reale Kernchecks haben Vorrang vor veraltetem Status
|
||||
- eindeutige Zustände: running, stopped, disabled, not-installed
|
||||
- sicherer PowerShell-Uninstaller mit automatischem Stoppen und Entfernen der
|
||||
Windows-Autostartaufgabe
|
||||
- Downloads bleiben standardmäßig erhalten
|
||||
|
||||
### Einstellungen
|
||||
|
||||
- Command-Center-Layout mit vier Bereichen
|
||||
- prominenter FLUX-Master-Schalter
|
||||
- Live-Gesundheitskarten
|
||||
- technische Pfade und Logs nur noch in aufklappbaren erweiterten Bereichen
|
||||
|
||||
## Grenzen
|
||||
|
||||
Image-to-Image-Pipeline bindet das Produktfoto real ein und verbessert die
|
||||
Artikelähnlichkeit deutlich, kann aber bei komplexen Logos oder extremen
|
||||
Perspektivwechseln keine pixelgenaue Reproduktion garantieren.
|
||||
@@ -0,0 +1,62 @@
|
||||
{
|
||||
"version": "1.15.0",
|
||||
"slice": "23",
|
||||
"date": "2026-07-07",
|
||||
"node_syntax": "passed for all .js and .mjs files",
|
||||
"json_validation": {
|
||||
"files_checked": 12,
|
||||
"bom_files": []
|
||||
},
|
||||
"html_validation": {
|
||||
"duplicate_ids": [],
|
||||
"required_settings_ids_present": true
|
||||
},
|
||||
"powershell_static_validation": {
|
||||
"unsafe_variable_colon_patterns": [],
|
||||
"uninstaller_encoding": "UTF-8 with BOM for Windows PowerShell 5.1"
|
||||
},
|
||||
"local_flux_mock_integration": {
|
||||
"source_upload": true,
|
||||
"load_image_node": true,
|
||||
"image_scale_node": true,
|
||||
"vae_encode_node": true,
|
||||
"sampler_uses_reference_latent": true,
|
||||
"reference_denoise_at_70_percent": 0.765,
|
||||
"progress_events_observed": 7,
|
||||
"final_progress": 100,
|
||||
"default_resolution": 768
|
||||
},
|
||||
"limitations": [
|
||||
"No real Windows/PowerShell 5.1 runtime or physical GPU was available in this build environment. The user must validate the final ComfyUI render on the Vendoo Windows system."
|
||||
],
|
||||
"changed_files": [
|
||||
"lib/ai-local-images.mjs",
|
||||
"lib/ai-model-photos.mjs",
|
||||
"lib/ai-model-jobs.mjs",
|
||||
"lib/db.mjs",
|
||||
"server.mjs",
|
||||
"public/index.html",
|
||||
"public/app.js",
|
||||
"public/style.css",
|
||||
"scripts/uninstall-local-flux.ps1",
|
||||
"package.json",
|
||||
"CHANGELOG.md",
|
||||
"FEATURES.md",
|
||||
"docs/SLICE_23_FLUX_REFERENCE_PROGRESS_SETTINGS.md"
|
||||
],
|
||||
"sha256": {
|
||||
"lib/ai-local-images.mjs": "a792c3d744f51352fd75e65c1dc29e8c3034b2526e7dfac2e0f21f2390696c5a",
|
||||
"lib/ai-model-photos.mjs": "af58af492d95f4a2d5d6d8a6cd8d7eca93af90de2ef6401db5c6f713c525a886",
|
||||
"lib/ai-model-jobs.mjs": "70e4046e7f47ff26d44fb8628851238c631711e910b617c8c5110ab0e0641c1a",
|
||||
"lib/db.mjs": "71bcc63191c9cfabe2115a05c6a1d208fee1456015fab20845b3cd1fd2de07cd",
|
||||
"server.mjs": "a577174d5ee885201406ca263a6489b2528aa24243b1c32c4b17b74faf5b725e",
|
||||
"public/index.html": "3d718a6553e63484949e82c6d8544d979e3a7ff6e9361e513fe47e0f362b3972",
|
||||
"public/app.js": "814c2ca5442bcab9cbfc7eac4883c34f1d003d0899f4d2eda25c0c9420175bb7",
|
||||
"public/style.css": "8d2f4b26a4974164e8f0e2a2248121529a4ac5ef351f49cf6536134602c94b9d",
|
||||
"scripts/uninstall-local-flux.ps1": "3bf3aa74f5cc1f2946bb2da637eb30fe8daec783a32f9721ebb0468e20df90bd",
|
||||
"package.json": "f7a483b9f9796655e6266d5614d2789ce579592578ee4b4e6d18ce6b35cb31ce",
|
||||
"CHANGELOG.md": "d55c9a2dd3715e4a597e583bef96d1974d62c1d0a0101888ab1ec5a4aea45ca1",
|
||||
"FEATURES.md": "61c711f50b1e25e7388de922ef6ef5eef4322470882a4579c7fefd46582c4f9d",
|
||||
"docs/SLICE_23_FLUX_REFERENCE_PROGRESS_SETTINGS.md": "6d7033671600bad73ae3f7fca8da95ce3db17ca16d88c80a16db8551d9d3d550"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,21 @@
|
||||
{
|
||||
"version": "1.18.9",
|
||||
"slice": "26.9",
|
||||
"file_count": 226,
|
||||
"checks": {
|
||||
"javascript_esm_syntax": true,
|
||||
"python_syntax": true,
|
||||
"json_validation": true,
|
||||
"html_duplicate_ids": false,
|
||||
"powershell_utf8_bom": true,
|
||||
"batch_utf8_bom": false,
|
||||
"encoding_scan": true,
|
||||
"public_npm_registry_only": true,
|
||||
"fresh_npm_ci_ignore_scripts": true,
|
||||
"runtime_private_data_excluded": true,
|
||||
"vto_utf8_mode": true,
|
||||
"human_parser_file_probe": true,
|
||||
"native_exit_code_wrapper": true,
|
||||
"non_admin_user_autostart": true
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,22 @@
|
||||
# Slice 28.1 – FLUX Runtime Health-Check
|
||||
|
||||
Version: 1.20.1
|
||||
|
||||
## Ziel
|
||||
|
||||
ComfyUI darf nicht mehr nach wenigen Sekunden als gestoppt gelten, während Python, Alembic und die ComfyUI-Datenbank noch initialisieren.
|
||||
|
||||
## Umsetzung
|
||||
|
||||
- Startskript wartet bis zu 180 Sekunden auf `http://127.0.0.1:8188/system_stats`.
|
||||
- PID-, Status- und Diagnoseinformationen unter `logs/local-flux-runtime-state.json`.
|
||||
- Laufzeitprotokolle:
|
||||
- `logs/local-flux-runtime.log`
|
||||
- `logs/local-flux-runtime-error.log`
|
||||
- ANSI-Sequenzen werden bei der Anzeige entfernt.
|
||||
- Ein vorzeitig beendeter Prozess wird sofort als Fehler erkannt.
|
||||
- Für das Vendoo Prompt-Studio werden Custom Nodes deaktiviert, da der Workflow nur Standard-Nodes nutzt.
|
||||
|
||||
## Bestandsschutz
|
||||
|
||||
ComfyUI, FLUX-Modell, Downloads, Datenbank, Uploads und Einstellungen bleiben erhalten.
|
||||
@@ -0,0 +1,31 @@
|
||||
# Slice 28 – FLUX Studio und vollständige VTO-Bereinigung
|
||||
|
||||
## Ziel
|
||||
|
||||
Vendoo verwendet keinen lokalen Virtual-Try-on-Stack mehr. FLUX/ComfyUI bleibt als eigenständiger, textbasierter Bildgenerator erhalten.
|
||||
|
||||
## Entfernt
|
||||
|
||||
- lokaler Python-/Torch-/ONNX-Bilddienst
|
||||
- Modelbibliothek und zugehörige API-Routen
|
||||
- alte Installations-, Start-, Stop- und Autostartpfade
|
||||
- zugehörige Einstellungen, Datenbanktabelle und Benutzeroberfläche
|
||||
- historische aktive Workflow-Pfade für Try-on
|
||||
|
||||
Beim ersten Setup-Lauf werden vorhandene Runtime- und Autostartreste entfernt. Eigene frühere Modelbilder werden nicht vernichtet, sondern nach `uploads/ai-generated/legacy-models` verschoben.
|
||||
|
||||
## FLUX Studio
|
||||
|
||||
- eigener Hauptmenüpunkt
|
||||
- freier Prompt
|
||||
- Stil, Format, Seed und Schritte
|
||||
- Live-Fortschritt
|
||||
- Vorschau und Download
|
||||
- persistente lokale Bibliothek
|
||||
- Übernahme in den Listing-Generator
|
||||
- nachträgliche Bearbeitung mit Zuschneiden, Drehen, Spiegeln, Helligkeit, Kontrast und Sättigung
|
||||
- bearbeitete Ausgaben als neue Version statt stiller Überschreibung
|
||||
|
||||
## Bestandsschutz
|
||||
|
||||
Nicht gelöscht werden Datenbank, Listings, normale Uploads, `.env`, API-Schlüssel, lokale FLUX-/ComfyUI-Installation, Modelle oder Downloads.
|
||||
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"slice": "28",
|
||||
"version": "1.20.0",
|
||||
"generated_at": "2026-07-08",
|
||||
"checks": {
|
||||
"javascript_esm_syntax": "passed",
|
||||
"json_validation": "passed",
|
||||
"html_duplicate_ids": "passed",
|
||||
"css_brace_balance": "passed",
|
||||
"sqlite_schema_and_cleanup_migration": "passed",
|
||||
"public_npm_lock_registry": "passed",
|
||||
"npm_lock_resolution_ignore_scripts": "passed_151_packages",
|
||||
"flux_mock_prompt_workflow": "passed",
|
||||
"flux_prompt_has_no_loadimage": "passed",
|
||||
"powershell_bom_policy": "passed",
|
||||
"encoding_scan": "passed",
|
||||
"runtime_and_user_data_excluded": "passed"
|
||||
},
|
||||
"notes": [
|
||||
"Native better-sqlite3 npm build could not finish in the Linux build environment because DNS access to GitHub/nodejs.org was unavailable.",
|
||||
"Windows PowerShell 5.1 runtime acceptance remains to be performed on the target Windows system."
|
||||
],
|
||||
"source_file_count": 191
|
||||
}
|
||||
@@ -0,0 +1,12 @@
|
||||
# Slice 29 – FLUX Quality & Settings Tabs
|
||||
|
||||
Version 1.21.0 optimiert FLUX.1-schnell für vier Schritte, ergänzt strukturierte Promptführung, Performanceprofile und eine horizontale Tab-Navigation in den Einstellungen.
|
||||
|
||||
## Profile
|
||||
- Schnell: 768 px, 4 Schritte
|
||||
- Ausgewogen: bis 1024 px, 4 Schritte
|
||||
- Detail: 1024 px, 6 Schritte
|
||||
- Eigene Werte: freie Auswahl
|
||||
|
||||
## Runtime
|
||||
Auto wählt bei NVIDIA-GPUs ab 12 GB VRAM das schnelle Profil, unter 8 GB das Low-VRAM-Profil und sonst Ausgewogen. Unsupported ComfyUI-Flags werden nicht erzwungen.
|
||||
@@ -0,0 +1,24 @@
|
||||
{
|
||||
"version": "1.21.0",
|
||||
"slice": "29",
|
||||
"checks": {
|
||||
"javascript_esm_files": 46,
|
||||
"javascript_syntax": "passed",
|
||||
"json_files": 14,
|
||||
"json_validation": "passed",
|
||||
"html_unique_ids": 484,
|
||||
"html_duplicate_ids": 0,
|
||||
"css_braces": "balanced",
|
||||
"powershell_utf8_bom": "passed",
|
||||
"batch_without_bom": "passed",
|
||||
"public_npm_registry": "passed",
|
||||
"mock_comfyui_prompt_flow": "passed",
|
||||
"prompt_mode_negative_prompt_empty": true,
|
||||
"flux_schnell_default_steps": 4,
|
||||
"settings_top_tabs": "implemented"
|
||||
},
|
||||
"limitations": [
|
||||
"Real Windows/NVIDIA performance depends on the installed GPU, VRAM, ComfyUI build and drivers.",
|
||||
"The build environment did not run the Windows PowerShell parser."
|
||||
]
|
||||
}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user