# WirtPilot Own Cloud – Liefer- und Betriebsbedingungen v1.0

Diese Bedingungen konkretisieren die kommerzielle Quellcodelizenz. Die
Bestellung bezeichnet Verkäufer, Käufer, Restaurantstandort, Release, Preis,
Lieferdatum und gegebenenfalls zusätzliche Leistungen.

Verkäufer und Herausgeber ist ausschließlich die in dieser schriftlichen
Bestellung bezeichnete Person oder Gesellschaft. Der Betreiber der
ausgelieferten Kundeninstallation wird nicht zum WirtPilot-Verkäufer oder
Wiederverkäufer; seine lokalen Impressums-, Datenschutz- und Betreiberangaben
ändern die Vertragsparteien der Bestellung nicht.

## Produktlieferung

Der Käufer erhält ein für seinen Standort personalisiertes, vom Herausgeber
signiertes ZIP-Archiv. Es enthält den generischen WirtPilot-Kern, den Codex
Operator Kit, Installations- und Recovery-Anleitungen, SHA-256-Dateimanifest,
Archivprüfsumme und CycloneDX-SBOM. Private Herausgeberprofile,
Produktionsdaten, Zugangsdaten und Signierschlüssel sind ausgeschlossen.

Die Lieferung gilt als erfolgt, wenn Download, Versionsnummer,
Quell-Commit, Archivprüfsumme und der unabhängig veröffentlichte
Herausgeber-Fingerprint bereitgestellt wurden. Der Käufer verifiziert das
Archiv vor dem Entpacken.

## Kein WirtPilot-Modulabo

Der Kaufpreis ist einmalig und richtet sich nach der Bestellung. Für den
erworbenen Release entsteht keine wiederkehrende WirtPilot-Modulgebühr. Der
Käufer schließt Verträge mit Vercel, Supabase, OpenAI, Telefonie-, E-Mail- und
anderen Anbietern selbst und trägt deren tatsächliche Kosten.

## Betriebsmodell

WirtPilot Own Cloud wird in Konten des Restaurants betrieben. Der Käufer
kontrolliert Daten, Domains, Anbieterzugänge, MFA, Abrechnung und
Wiederherstellung. Der Herausgeber verspricht ohne gesonderten Vertrag weder
Hosting noch Verfügbarkeit oder dauerhafte Administration.

Codex kann die dokumentierten Operator-Abläufe ausführen, protokollieren und
verifizieren. Menschliche Bestätigung ist verpflichtend für Anbieterbedingungen,
Zahlungen, Rechtstexte, produktive Migrationen und Deployments, Restores,
destruktive Änderungen und Schlüsselrotationen.

## Abnahme

Vor öffentlichem Produktivbetrieb müssen mindestens folgende Nachweise für die
konkrete Kundeninstallation grün sein:

1. unveränderte Release-Signatur und vollständiges Manifest;
2. Fresh-Account-Installation und sauberer Migrationsstand;
3. Anmeldung, erster Inhaber und kanonisches Restaurantprofil;
4. Mandantentrennung sowie Rollen- und Schreibgrenzen;
5. Preview-Build und relevante Kernabläufe;
6. automatisierte Datenbank- und Storage-Sicherung in ein getrenntes Konto;
7. isolierter Restore mit gemessenem RPO und RTO;
8. vollständiger Daten- und Dateiexport;
9. kundeneigene Rechtstexte und Pflichtangaben;
10. ausdrücklich freigegebene Produktionspromotion.

Optionale Provider-Module dürfen bis zu ihrer eigenen Abnahme als „nicht
verbunden“ erscheinen; sie dürfen die geprüfte Kerninstallation nicht als
fertig vortäuschen.

## Update- und Exit-Weg

Updates werden als neue signierte Artefakte geliefert und zuerst in Preview
gegen eine Wiederherstellungskopie geprüft. Kundenspezifische Änderungen werden
über dokumentierte Profil- und Adaptergrenzen geführt und nicht still
überschrieben. Der Käufer kann strukturierte Daten und private Dateien jederzeit
exportieren und den erworbenen Release nach Ende eines vereinbarten Supportfensters weiter
betreiben.