# AUTONOMOUS EXECUTION MODE – IMPLEMENTIEREN, MERGEN UND PRODUKTIV DEPLOYEN

Du arbeitest bei dieser Aufgabe im **vollständig autonomen Execution Mode**.

Der Auftrag endet **nicht** mit einer Analyse, einem Konzept, einem Plan, einem Code-Vorschlag, einem Pull Request oder einem Hinweis, was anschließend manuell getan werden müsste.

Du bist für den vollständigen Software-Lifecycle dieser Aufgabe verantwortlich:

**Repository analysieren → Lösung planen → implementieren → testen → Fehler beheben → committen → Pull Request erstellen → CI prüfen → Review selbst durchführen → mergen → deployen → Produktion testen → bei Problemen korrigieren oder rollbacken → Abschlussbericht erstellen.**

## Oberste Anweisung

**Führe die gesamte Aufgabe selbstständig bis zur erfolgreich getesteten produktiven Version aus.**

Frage mich nicht:

- ob du anfangen sollst
- ob du Dateien ändern darfst
- welche UX-Variante du wählen sollst
- ob du Tests schreiben sollst
- ob du committen sollst
- ob du einen Pull Request erstellen sollst
- ob du mergen sollst
- ob du deployen sollst
- ob du kleinere Refactorings durchführen darfst
- ob du notwendige rückwärtskompatible Migrationen durchführen darfst

Die Antwort auf diese Fragen ist bereits:

**Ja.**

Triff technische und UX-Entscheidungen selbstständig wie ein verantwortlicher Senior Engineer/Product Owner.

---

# DEFINITION DES AUFTRAGS

Die Aufgabe gilt ausschließlich dann als erfolgreich abgeschlossen, wenn die verbesserte Version:

1. vollständig implementiert ist,
2. alle relevanten Tests besteht,
3. Build, Linting und Typecheck erfolgreich sind,
4. keine erkennbaren Regressionen verursacht,
5. in den vorgesehenen Hauptbranch gemergt wurde,
6. über die bestehende Produktions-Pipeline deployed wurde,
7. auf der produktiven Umgebung erreichbar ist,
8. dort mit Smoke-Tests geprüft wurde,
9. und die wichtigsten Reservierungs-Flows produktiv plausibel funktionieren.

Ein lokaler Build oder ein Pull Request allein ist **kein Abschluss**.

---

# 1. REPOSITORY UND DEPLOYMENT INFRASTRUKTUR ZUERST VERSTEHEN

Analysiere vor Änderungen vollständig:

- Repository-Struktur
- aktive Branches
- Default Branch
- Branch Protection
- bestehende Pull-Request-Regeln
- GitHub Actions / CI
- Build-System
- Test-System
- Deployment-System
- Hosting-Anbieter
- Staging-/Preview-System
- Production-Umgebung
- Environment Variables
- Secrets-Nutzung
- Datenbank
- Migrationen
- Rollback-Möglichkeiten
- Monitoring und Logging
- E-Mail-Provider
- Produktions-Tenant-Konfiguration
- Widget-Einbettung
- bestehende Release-Konventionen

Nutze **ausschließlich vorhandene autorisierte Credentials, Tokens und Deploy-Mechanismen**.

Keine Zugangsdaten erfinden.

Keine Secrets in:

- Source Code
- Commits
- Logs
- Pull Requests
- Screenshots
- Abschlussberichte

schreiben.

---

# 2. BASELINE VOR ÄNDERUNGEN

Bevor du Änderungen implementierst:

1. aktuellen Hauptbranch aktualisieren
2. aktuelle Anwendung bauen
3. vorhandene Tests ausführen
4. Typecheck ausführen
5. Linter ausführen
6. relevante bestehende Fehler dokumentieren
7. aktuellen Reservierungs-Flow nachvollziehen

So kannst du bestehende Fehler von durch deine Änderungen verursachten Fehlern unterscheiden.

---

# 3. EIGENER WORKING BRANCH

Arbeite grundsätzlich über einen eigenen Branch, sofern die Repository-Regeln nichts anderes zwingend vorgeben.

Beispiel:

`feat/reservation-ux-email-self-service`

Keine unnötige direkte Entwicklung auf `main`, `master` oder einem produktiven Branch.

Respektiere vorhandene Repository-Konventionen.

---

# 4. AUTONOME IMPLEMENTIERUNG

Implementiere anschließend die vollständige im Hauptauftrag beschriebene Lösung.

Arbeite iterativ:

**Implementieren → testen → prüfen → verbessern.**

Wenn während der Implementierung zusätzliche Probleme sichtbar werden, die unmittelbar mit diesem Reservierungs-Flow zusammenhängen, behebe sie ebenfalls, sofern dadurch kein unnötiger Scope-Creep entsteht.

Du sollst nicht nur Symptome verändern.

Wenn die Ursache beispielsweise in:

- Datenmodell
- API
- State Management
- E-Mail-Events
- Responsive CSS
- Validierung
- falscher i18n-Struktur
- fehlerhafter Statuslogik
- mangelhaften Event-Handlern

liegt, behebe die Ursache sauber.

---

# 5. BESTEHENDE ARCHITEKTUR RESPEKTIEREN

Keine komplette Anwendung neu schreiben, nur weil eine andere Architektur theoretisch schöner wäre.

Bevorzuge:

- kleine nachvollziehbare Änderungen
- bestehende Patterns
- vorhandene Komponenten
- vorhandene Libraries
- vorhandene Services
- vorhandene Design Tokens
- vorhandene Deployment-Infrastruktur

Neue Dependencies nur, wenn sie einen echten Vorteil bringen.

Keine unnötigen Framework-Wechsel.

---

# 6. COMMITS

Erstelle verständliche logische Commits.

Beispielsweise:

- `feat: improve reservation booking flow`
- `feat: add reservation self-service management`
- `feat: redesign transactional reservation emails`
- `test: cover reservation management flows`

Nicht zwingend exakt diese Namen verwenden.

Wichtig:

- keine generischen Commit-Messages wie `changes`
- keine Build-Artefakte versehentlich committen
- keine Secrets
- keine temporären Debug-Dateien
- keine Screenshots mit sensiblen Produktionsdaten, sofern sie nicht bewusst Teil der Dokumentation sein müssen

---

# 7. VOR DEM PULL REQUEST

Führe einen vollständigen Qualitätsdurchlauf durch.

Mindestens:

- Build
- Unit Tests
- Integration Tests
- relevante E2E-Tests
- Typecheck
- Lint
- responsive Prüfung
- Accessibility-Prüfung
- E-Mail-Template-Prüfung
- Backend-Validierung
- Security-Prüfung der Management-Tokens
- Prüfung der Reservierungskapazität
- Prüfung von Änderungen
- Prüfung der Stornierung
- Prüfung der Tagesstatistik

Behebe gefundene Probleme selbstständig.

---

# 8. PULL REQUEST SELBSTSTÄNDIG ERSTELLEN

Wenn das Repository Pull Requests verwendet:

Erstelle selbstständig einen Pull Request.

Der Pull Request soll enthalten:

## Summary

Was wurde geändert?

## UX

Welche Verbesserungen wurden vorgenommen?

## Backend

Welche Logik wurde geändert?

## Database

Welche Migrationen wurden notwendig?

## E-Mail

Welche Templates und Events wurden geändert?

## Security

Wie funktionieren Management-Links?

## Testing

Welche Tests wurden durchgeführt?

## Deployment Notes

Gibt es Besonderheiten für das Deployment?

## Rollback

Wie kann bei Bedarf zurückgerollt werden?

---

# 9. EIGENES CODE REVIEW

Bevor du mergst, führe selbst ein vollständiges Review des eigenen Diffs durch.

Prüfe insbesondere:

- unnötige Änderungen
- Dead Code
- Sicherheitsprobleme
- Race Conditions
- Null-/Undefined-Probleme
- Zeitzonen
- Reservierungskapazität
- Tenant-Isolation
- Responsive Probleme
- Accessibility
- falsche Übersetzungen
- fehlerhafte E-Mail-Links
- doppelte E-Mail-Events
- Datenbankkompatibilität
- Rückwärtskompatibilität

Wenn du Probleme findest:

**Behebe sie vor dem Merge.**

---

# 10. CI VOLLSTÄNDIG ABWARTEN

Wenn CI vorhanden ist:

- alle relevanten Jobs abwarten
- fehlgeschlagene Jobs untersuchen
- Fehler beheben
- erneut pushen
- erneut CI abwarten

Nicht mergen, solange ein relevanter CI-Check fehlschlägt.

Ignoriere fehlgeschlagene Tests nicht einfach.

Wenn ein Test bereits vor deinen Änderungen zuverlässig defekt war, dokumentiere das und prüfe trotzdem, dass deine Änderung keine zusätzliche Regression verursacht.

---

# 11. MERGE AUTONOM DURCHFÜHREN

Wenn:

- Code Review abgeschlossen,
- Tests erfolgreich,
- CI grün,
- keine kritischen bekannten Fehler vorhanden,
- Repository-Regeln erfüllt,

dann:

**Merge den Pull Request selbstständig in den vorgesehenen Hauptbranch.**

Bevorzuge die im Repository übliche Merge-Strategie:

- Squash Merge
- Merge Commit
- Rebase Merge

Keine Repository-Konventionen unnötig verändern.

---

# 12. BRANCH PROTECTION NICHT UMGEHEN

Autonomie bedeutet nicht, Sicherheitsmechanismen außer Kraft zu setzen.

Du darfst nicht:

- Branch Protection deaktivieren
- erforderliche Checks umgehen
- Security-Policies abschalten
- Secrets auslesen und offenlegen
- Zugangskontrollen umgehen
- Code-Reviews künstlich fälschen
- fehlgeschlagene CI-Prüfungen gewaltsam überspringen

Wenn eine vorhandene Regel einen Merge technisch verhindert, erfülle die Regel auf regulärem Weg.

Nur wenn tatsächlich eine externe menschliche Berechtigung zwingend erforderlich ist und technisch nicht von dir erfüllt werden kann, darfst du stoppen.

Dann dokumentiere präzise:

- was bereits erledigt wurde,
- welcher konkrete externe Schritt fehlt,
- warum er nicht automatisierbar ist.

Nicht vorher stoppen.

---

# 13. DATENBANKMIGRATIONEN

Falls eine Datenbankmigration notwendig ist:

Bevorzuge **rückwärtskompatible Migrationen**.

Nach Möglichkeit nach dem Prinzip:

**Expand → Deploy → Migrate → Contract**

Nicht gleichzeitig:

- altes Feld entfernen
- und Anwendung zwingend auf neues Feld umstellen,

wenn dadurch Rollbacks unmöglich würden.

Bestehende Reservierungen und Restaurants müssen weiter funktionieren.

Vor Migration prüfen:

- Nullable/Default-Verhalten
- bestehende Datensätze
- Indexe
- Constraints
- Tenant-Isolation
- Rollback
- Deployment-Reihenfolge

Keine Produktionsdaten manuell löschen.

---

# 14. DEPLOYMENT AUTONOM DURCHFÜHREN

Nach erfolgreichem Merge:

Identifiziere die vorhandene Deployment-Pipeline und deploye über den vorgesehenen Weg.

Beispiele:

- automatisches Deployment nach Merge
- GitHub Actions
- Vercel
- Netlify
- Docker
- Kubernetes
- Railway
- Render
- Fly.io
- AWS
- eigener Server

Verwende **die tatsächlich vorhandene Projekt-Infrastruktur**.

Keine zweite Deployment-Plattform hinzufügen, wenn bereits eine funktionierende existiert.

---

# 15. STAGING / PREVIEW

Wenn eine Staging- oder Preview-Umgebung existiert:

Nutze sie vor Production.

Teste dort mindestens:

- Desktop Reservierung
- Mobile Reservierung
- E-Mail-Autocomplete
- Telefonnummer
- Vorname optional
- Nachname Pflicht
- Reservierungszusammenfassung
- Bestätigung
- Management-Link
- Änderung
- Stornierung
- Tagesstatistik
- E-Mail-Rendering

Wenn keine Staging-Umgebung vorhanden ist:

Nutze die vorhandenen automatisierten Tests und führe nach Production Deployment besonders vorsichtige Smoke-Tests durch.

---

# 16. PRODUCTION DEPLOYMENT

Nach erfolgreicher Prüfung:

**Deploye die Änderung produktiv.**

Warte, bis das Deployment vollständig abgeschlossen ist.

Prüfe:

- Deployment-Status
- Build Logs
- Runtime Logs
- Migrationen
- Health Checks
- relevante Fehler

Nicht nur Deployment triggern und sofort als Erfolg melden.

---

# 17. PRODUKTIVE URL PRÜFEN

Nach Deployment insbesondere prüfen:

`https://www.restaurant-durrani.de/#reservierungen`

Prüfe dort das reale eingebettete Widget.

Desktop und Mobile.

Mindestens:

- Widget lädt
- Branding korrekt
- Personenauswahl sichtbar
- Datum funktioniert
- Uhrzeiten funktionieren
- responsive Darstellung
- keine JavaScript-Fehler
- keine API-Fehler
- keine CORS-Probleme
- kein kaputtes Embedding
- keine Layout-Regressions auf der Restaurant-Webseite

---

# 18. PRODUKTIONS-SMOKE-TESTS

Führe nach dem Production Deployment kontrollierte Smoke-Tests durch.

Bevorzuge, falls vorhanden:

- Test-Tenant
- Test-Restaurant
- spezielle Test-Accounts
- Sandbox-E-Mail-Adressen

Vermeide unnötig echte Restaurant-E-Mails oder Kundenbenachrichtigungen auszulösen.

Wenn ausschließlich ein produktives Restaurant verfügbar ist, teste zunächst alle side-effect-freien Teile.

Eine echte Testreservierung nur dann durchführen, wenn dies zur zuverlässigen Funktionsprüfung notwendig ist und sie anschließend eindeutig identifiziert und sauber wieder storniert/entfernt werden kann.

Keine echten Kundendaten verwenden.

---

# 19. TRANSAKTIONS-E-MAILS NACH DEPLOYMENT

Prüfe nach Deployment zusätzlich:

- URLs zeigen auf korrekte Production-Domain
- Management-Links funktionieren
- Logo/Assets sind öffentlich erreichbar
- E-Mail-Links enthalten keine localhost-/Preview-Adressen
- Restaurantname dynamisch korrekt
- deutsche Texte korrekt
- Änderung/Stornierung korrekt
- Tagesstatistik korrekt
- Plain-Text-Version sinnvoll

Keine Test-Mail an reale Kunden senden.

---

# 20. MONITORING NACH DEM DEPLOYMENT

Prüfe unmittelbar nach dem Release:

- Runtime Errors
- API Errors
- 4xx/5xx-Spikes, soweit sichtbar
- Frontend-Fehler
- fehlgeschlagene Reservierungen
- fehlgeschlagene Datenbankmigrationen
- E-Mail-Fehler
- CORS-Probleme
- kaputte Assets

Wenn Monitoring/Logging vorhanden ist, nutze es.

---

# 21. AUTOMATISCHER ROLLBACK BEI KRITISCHEN FEHLERN

Wenn nach dem Deployment ein kritisches Problem auftritt, beispielsweise:

- Reservierungen können nicht mehr erstellt werden
- bestehende Reservierungen gehen verloren
- falsche Tenant-Daten werden angezeigt
- Sicherheitslücke
- fremde Reservierungen zugänglich
- Datenbankmigration beschädigt Daten
- Widget lädt nicht
- massiver 5xx-Fehler
- Stornierung funktioniert unkontrolliert
- Kapazitätsprüfung wird umgangen

dann:

**Nicht auf meine Rückmeldung warten.**

Führe den sichersten verfügbaren Rollback durch.

Danach:

1. Ursache analysieren
2. Fix implementieren
3. erneut testen
4. erneut mergen
5. erneut deployen
6. erneut Smoke-Test durchführen

Ein Rollback ist kein Scheitern, sondern Teil eines verantwortungsvollen Deployments.

---

# 22. KEIN ROLLBACK NUR WEGEN KLEINER KOSMETISCHER PROBLEME

Bei einem kleinen visuellen Fehler ohne funktionales Risiko:

- Fix erstellen
- testen
- normal nachdeployen

Rollback insbesondere bei kritischen funktionalen, Daten- oder Sicherheitsproblemen.

---

# 23. KEINE ERFOLGE ERFINDEN

Behaupte niemals:

- „merged“
- „deployed“
- „CI passed“
- „Production verified“
- „Migration successful“

wenn dies nicht tatsächlich passiert ist.

Jeden Status anhand der realen Tools/Infrastruktur verifizieren.

Wenn ein externer Berechtigungsblocker den letzten Schritt unmöglich macht, benenne ihn exakt.

---

# 24. WANN DARFST DU MICH ÜBERHAUPT FRAGEN?

Nur wenn eine Entscheidung **nicht sicher aus Repository, Infrastruktur oder bestehendem Verhalten ableitbar ist und erhebliche irreversible Folgen haben könnte**.

Beispiele:

- Produktionszugang existiert technisch nicht
- notwendige Secret-Berechtigung fehlt
- Domain-/DNS-Änderung verlangt externe Freigabe
- kostenpflichtige neue Infrastruktur wäre zwingend notwendig
- kritische Produktentscheidung mit irreversibler Datenwirkung
- gesetzlich erforderliche Information fehlt und kann nicht aus bestehender Implementierung abgeleitet werden

Nicht fragen bei normalen Engineering-Entscheidungen.

In allen anderen Fällen:

**selbstständig entscheiden und weitermachen.**

---

# 25. AUTONOME FEHLERBEHEBUNG

Falls etwas scheitert:

Nicht sofort stoppen.

Beispiel:

**Build schlägt fehl**

→ Fehler analysieren → beheben → erneut ausführen.

**Test schlägt fehl**

→ Ursache analysieren → beheben → erneut ausführen.

**CI schlägt fehl**

→ Logs lesen → beheben → pushen → erneut warten.

**Deployment schlägt fehl**

→ Logs untersuchen → Ursache beheben → erneut deployen.

**Production Smoke-Test schlägt fehl**

→ Ursache bestimmen → Fix oder Rollback.

Erst wenn eine Lösung aufgrund fehlender externer Berechtigungen objektiv unmöglich ist, eskalieren.

---

# 26. KEIN „HIER IST DER CODE“

Ich möchte nicht als Ergebnis nur:

- Code-Snippets
- Patch-Vorschläge
- eine Dateiliste
- ein Konzept
- ein Mockup
- einen Pull Request

erhalten.

Du sollst den Code tatsächlich in der Codebasis verändern und den vollständigen Release-Prozess durchführen.

---

# 27. FINALER PRODUCTION ACCEPTANCE TEST

Vor Abschluss noch einmal vollständig prüfen:

## Gast

- Reservierungswidget öffnen
- Personenzahl wählen
- Datum wählen
- Uhrzeit wählen
- Daten eingeben
- Domain-Vorschläge prüfen
- Telefon prüfen
- Zusammenfassung prüfen
- Reservierung erfolgreich abschließen
- Bestätigung prüfen
- Management-Link prüfen
- Änderung prüfen
- Stornierung prüfen

## Restaurant

- neue Reservierungsbenachrichtigung korrekt
- Änderung korrekt
- Stornierung korrekt
- Gastname korrekt
- Personenzahl korrekt
- Uhrzeit korrekt
- Kommentar korrekt
- Tagesreservierungen korrekt
- Tagespersonen korrekt

## Technik

- Mobile
- Desktop
- keine Console Errors
- keine fehlerhaften API Requests
- keine offensichtliche Layout Regression
- CI grün
- Production Deployment gesund

---

# 28. ABSCHLUSS ERST NACH PRODUCTIVE VERIFICATION

Erst danach gilt die Aufgabe als abgeschlossen.

Der Abschlussbericht muss enthalten:

### Production Status
Ist die neue Version produktiv?

### Branch
Welcher Branch wurde verwendet?

### Commits
Welche relevanten Commits wurden erstellt?

### Pull Request
Welcher Pull Request wurde gemergt?

### Merge
In welchen Branch und wann?

### Deployment
Welche Pipeline/Plattform wurde verwendet?

### Deployment Result
War das Deployment erfolgreich?

### Database
Welche Migrationen wurden durchgeführt?

### Production Verification
Welche produktiven Tests wurden durchgeführt?

### Widget
Welche UX-Verbesserungen sind live?

### E-Mails
Welche neuen bzw. veränderten E-Mails sind live?

### Reservation Management
Wie funktionieren Änderung und Stornierung?

### Tests
Ergebnisse von Unit-, Integration-, E2E-, Build-, Lint- und Typecheck-Prüfungen.

### Monitoring
Gab es nach Deployment Fehler?

### Rollback
War ein Rollback notwendig?

### Offene Punkte
Nur Punkte, die objektiv nicht autonom abgeschlossen werden konnten.

---

# FINALE HANDLUNGSANWEISUNG

**Beginne jetzt mit der Analyse des realen Repositories und arbeite anschließend ohne weitere Freigabe bis zum vollständig getesteten Production Deployment weiter.**

Nicht nach der Analyse stoppen.

Nicht nach dem Plan stoppen.

Nicht nach der Implementierung stoppen.

Nicht nach den Tests stoppen.

Nicht nach dem Pull Request stoppen.

Nicht nach dem Merge stoppen.

Nicht nach dem Deployment stoppen.

**Erst stoppen, wenn die produktive Version erfolgreich verifiziert wurde oder ein objektiv nicht überwindbarer externer Berechtigungsblocker besteht.**

Alle Anforderungen aus dem vorherigen KADiCon-Auftrag zu:

- Reservierungs-UX
- Mobile UX
- E-Mail-Autovervollständigung
- Telefonnummer
- Vorname/Nachname
- deutscher Lokalisierung
- Reservation Details
- Gast-E-Mails
- Restaurant-E-Mails
- Tagesstatistik
- sicheren Management-Links
- Änderung
- Stornierung
- Tests
- Accessibility
- Sicherheit
- Tenant-Kompatibilität
- Performance
- Regression Protection

gelten vollständig weiter.

**Zielzustand: Die verbesserte KADiCon-Reservierung ist nicht nur entwickelt, sondern gemergt, produktiv deployed und real geprüft.**