Standalone-Booking-Desk für Partner-Ops (Standalone Booking Desk Fuer Partner Ops)

Standalone-Booking-Desk für Partner-Ops

Partner operators may need a dedicated desk URL while still consuming the shared auth remote.

same remote, own origin, auth remote shared

Aynı remote, iki teslimat kanalı.

Begriffe, dort definiert, wo sie zuerst auftauchen

📦 Partner Capacity
Kapazitätswahrheit des Fährpartners — keine flache CRUD-Zeile.

📦 Ticket Lifecycle
Übergänge wie sold → used → canceled.

📦 Discount Workflow
Berechnen / genehmigen / zurücknehmen mit Autorität.

📦 Booking Desk
Oberfläche für Tickets und Fahrzeugkontext.

Wer diese Begriffe vermischt, verwechselt UI-State mit Integrationswahrheit.

Form des Problems

Partner operators may need a dedicated desk URL while still consuming the shared auth remote.

same remote, own origin, auth remote shared

Die Trennung, die trägt

Aynı remote, iki teslimat kanalı.

same remote, own origin, auth remote shared
        ↓
   explicit contract

Wo Produktion bricht

Incidents wachsen, wenn Radius, Identität oder Deploy-Annahmen implizit bleiben.

Die am häufigsten verwechselten Zuordnungen

❌ Eine App ist immer sicherer
✓ Ohne klare Grenzen ist eine App fragiler

❌ Config hardcoden
✓ Radius, Remote-URLs und Expose-Pfade sind Verträge

❌ Vendor/API-Wahrheit ist UI-State
✓ Vendor-Feed ist Evidenz; Ops-State ist Entscheidung

Checkliste zur Prüfung des eigenen Systems

1. Ownership-Grenze in einem Satz schreiben.
2. Wenn der Vertrag sich ändert — wer deployt?
3. Bei Timeout/Vendor-Delay: was zeigt die UI?
4. Embedded und Standalone getrennt testen?
5. Deny-list: Vendor/Domain-Leakage in Texten?

Was aus diesem Teil bleiben sollte

1. Verträge müssen sichtbar sein: Expose-Pfade, Radius, Ticket-Status, Remote-URLs.
2. Die Lücke zwischen UI und Externem ist Design, kein Bug.
3. Unabhängiges Deploy heißt unabhängiges Rollback.

Die Grenze, die Sie verstecken, findet Sie in Produktion.