# Daily Log — 2026-09-06 ## RwG: Produktions-Feed HAT funktioniert (12:28 CEST, Kais-Screenshot Feed History Produktion) - MEINE GESTRIGE VERMUTUNG WIDERLEGT: Der Cron hat gefeuert, Google hat alles angenommen. ``` 05.09. 07:00 GMT+2 Merchant Success Complete 23 Datensaetze 22 NEU 0 Fehler 0 Warnungen 05.09. 07:01 GMT+2 Services Success Complete 23 Datensaetze 22 NEU 0 Fehler 0 Warnungen 06.09. 07:00 GMT+2 Merchant Success Complete 23 Datensaetze 0 neu 0 Fehler 0 Warnungen 06.09. 07:01 GMT+2 Services Success Complete 23 Datensaetze 0 neu 0 Fehler 0 Warnungen ``` - 22 NEUE Datensaetze am 05.09. = exakt unsere 22 angelegten Betriebe, plus Durrani = 23. Die Uebernahme hat also vollstaendig funktioniert. - Heute 0 neue, weil sich seit gestern nichts geaendert hat. Konsistent. - Gut, dass ich gestern beide Zweige offengelassen und um genau diesen Screenshot gebeten habe, statt die Cron-These als Befund zu melden. - KAIS' BEOBACHTUNG "1 Merchant in Produktion" passt nicht dazu. Um erneutes Nachsehen gebeten: entweder gefilterte Ansicht oder die Seite hing hinterher. - NEUE AUFFAELLIGKEIT, bewusst als Beobachtung und nicht als Befund gemeldet: In der Liste erscheinen nur Merchant und Services. Der AVAILABILITY-Feed fehlt. Bei uns laufen drei Feeds (Merchant sofort, Services +1 Min, Availability +2 Min); in Staging laedt Availability 118260 Zeitfenster hoch. Ohne Availability weiss Google, dass es die Betriebe gibt, aber nicht wann buchbar - dann springt keiner auf Ready. - Kais soll pruefen, ob die Liste im Bild nur abgeschnitten war oder ob die Availability-Zeile wirklich fehlt. ## RwG: Widerspruch bei Google - Feed empfangen, Inventory leer (12:31 CEST) - Zweiter Screenshot: "Total received inventory" in der PRODUKTION zeigt 1 merchants. Nur Restaurant Durrani (4e22f973), Matched Yes, RwG-E2E: **Processing** (nicht Ready). - WIDERSPRUCH: Feed History meldet 23 Datensaetze empfangen und 22 neu mit 0 Fehlern, das Inventory zeigt 1. Beides dieselbe Umgebung, beides Google. - ENTSCHEIDENDES DETAIL ist nicht die Zahl, sondern Durranis Status: Processing statt Ready. In der Sandbox stehen 23 Betriebe auf Ready, in der Produktion kommt nicht einmal der eine durch. - THESE (als solche gemeldet): Die PRODUKTIONS-Anbindung ist bei Google noch nicht freigeschaltet. Sandbox laeuft, Produktion nicht. Erklaert beides gleichzeitig - Durranis Dauerstatus Processing und die nicht uebernommenen 22. - INDIZ dafuer: logTestSlots() im Availability-Prozessor enthaelt drei fest verdrahtete PRODUKTIONS-Merchant-IDs aus "Google case 05341814 (2026-05-20)". Es lief also im Mai schon eine Produktions-Abnahme mit Google. Ob sie abgeschlossen wurde, ist unbekannt. - ANGEFORDERT: (1) Alerts-Seite - dort ist ein ROTER PUNKT, im Zweifel steht dort die Antwort. (2) Home oder Configuration, dort steht der Status der Anbindung. (3) Weiterhin offen: Availability-Zeile in der Feed History. - KONSEQUENZ falls die These stimmt: Auf unserer Seite ist nichts kaputt. Es waere ein Vorgang bei Google ueber den Support mit der bestehenden Fallnummer 05341814. ## RwG: URSACHE GEFUNDEN - Google hat die Produktions-Anbindung ABGESCHALTET (12:37 CEST) - Kais schickte sechs Screenshots (Alerts, E2E-Onboarding-Plan Teil 1-3, Account and Users, Account features). - BEFUND, unmissverstaendlich: Configuration > Account and Users > Integration status: "RwG: E2E Integration - Disabled. Your integration has been disabled. Please resolve reported issues before re-enabling." Partner-ID 20002024, Konto KADiCon. - ERKLAERT ALLES: Feed wird angenommen (23 Datensaetze, 0 Fehler), Inventory bleibt bei 1, Durrani haengt auf Processing. Die Sandbox laeuft, weil dort nichts abgeschaltet ist. Meine These von heute frueh war richtig. - AUF UNSERER SEITE IST NICHTS KAPUTT. Die 22 Betriebe sind vollstaendig eingerichtet und warten auf die Freischaltung. ### E2E-Onboarding-Plan: 25 % complete, 8 Schritte, 7 offen 1 Setup fertig | 2 Sandbox-Feeds 2 von 3 | 3 Sandbox-Booking-Server 1/20 Lookups, 0/10 Create, 0/10 Update | 4 Sandbox-RTU 0/10 | 5 Prod-Feeds: Merchant fertig, Services fertig, AVAILABILITY FEHLT GANZ | 6 Prod-Booking-Server 0/20, 0/3, 0/3 | 7 Prod-RTU 0/3 | 8 Google Review nicht begonnen. - Schwerpunkt ist NICHT der Feed, sondern der BUCHUNGSVERKEHR. Google will Anfragen am Booking-Server sehen. ### Der eine echte Fehler bei uns - "Availability feeds ready in Production: You have uploaded no feed in the past 7 days". Merchant und Services laufen taeglich sauber, Availability hat NIE hochgeladen. Meine Beobachtung von heute frueh woertlich bestaetigt. - AUSGESCHLOSSEN: fehlende Zugangsdaten. Alle drei SFTP-Nutzer sind in der Produktion gesetzt und untereinander wie gegen Staging verschieden, SFTP-Schluessel gesetzt, Fenster-Vorgabe identisch (Standard 6 Wochen). - Unterschied zu den anderen zwei: Availability laedt Reservierungen/Tische/Kombinationen, erzeugt eine viel groessere Datei und GZIPPT sie. Weiter komme ich ohne Produktions-Logs nicht. Der Logzugriff ist damit vom theoretischen Wunsch zum konkreten Blocker geworden. ### Vorhandenes Werkzeug fuer Schritt 3/4/6/7 - tools/rwg/booking-server-e2e.ts + tools/rwg/run-booking-e2e.sh existieren bereits im Repo. Faehrt /v3/BatchAvailabilityLookup, /v3/CreateBooking (mit Idempotenz-Pruefung), /v3/UpdateBooking (Aenderung und Storno) gegen die Sandbox. Durranis Sandbox-Merchant vorbelegt, Passwort wird verdeckt eingelesen. - Ein Lauf ergibt ca. 2 Lookups / 2 Buchungen / 2 Aenderungen. Zaehler "1 von 20" passt zu genau einem bisherigen Lauf -> rund zehn weitere noetig. ### Nebenbefunde - Zwei OFFENE Alerts mit Status Error: "Booking server success rates low" fuer GetWaitlistEntry und BatchGetWaitEstimates (Wartelisten-Endpunkte). Sollte mit Google geklaert werden, kann die Erfolgsquote druecken. - Account features Produktion: "Change max party size to: 10". Durrani laesst bei uns Gruppen bis 16 zu - Google wuerde abschneiden. - LIEFERUNG: BEFUND-produktion-abgeschaltet.md an Kais (TG 11362/11363), Kopie im Vault. - EMPFEHLUNG an Kais: zuerst der Availability-Feed, weil ohne ihn Schritt 5 nie fertig wird. ## RwG SCHRITT 1 ERLEDIGT: Availability-Feed-Ursache gefunden und behoben (12:45 CEST) - Kais: "Schritt fuer Schritt start". Begonnen mit dem Availability-Feed, wie empfohlen. - URSACHE OHNE PRODUKTIONS-LOGS GEFUNDEN, weil sie im eigenen Repo dokumentiert ist: Commit 791541ef vom 01.09.2026 05:27 UTC, "fix(core-utils): treat missing weekday in schedule as closed". Kommentar im Code woertlich: "this aborted the entire availability feed for all merchants when a single one had a gap." getDaySchedule() gab bei fehlendem Wochentag undefined zurueck -> jeder Aufrufer, der .closed/.rules liest, stuerzt ab -> der gesamte Availability-Feed bricht ab. Merchant und Services sind nicht betroffen, weil sie den Zeitplan nicht anfassen. Deckt sich exakt mit dem Bild: Merchant und Services taeglich sauber, Availability nie. - ALLE 23 PRODUKTIONSBETRIEBE GEPRUEFT: GENAU EINER hatte die Luecke - ALIBABA Doener und Pizza, Sonntag fehlte. Die anderen 22 vollstaendig. - URSPRUNG DER LUECKE: ALIBABA war der einzige, den ich am 04.09. VON HAND eingerichtet habe; ich hatte den Staging-Zeitplan woertlich uebernommen, und dort fehlt der Sonntag. Die 22 aus anlegen.py sind vollstaendig, weil deren Staging-Plaene alle sieben Tage tragen. - BEHOBEN: Sonntag als {closed:true, rules:[]} ergaenzt. Kontrolle: 7 Tage, 6 offen (unveraendert), Montag 43 Fenster (unveraendert), Sonntag 0, Place-ID/Telefon/Zeitzone unangetastet, googleReservations weiter true. - EHRLICHE EINSCHRAENKUNG an Kais: Der Ausloeser ist entfernt, BEWIESEN ist es erst beim naechsten Feed-Lauf morgen 05:00 UTC. Erscheint dann eine Availability-Zeile in der Feed History, war es das. Erscheint keine, liegt es woanders und der Logzugriff wird zwingend. - EMPFEHLUNGEN weitergegeben: (1) Pruefen, ob die PRODUKTION den Commit vom 01.09. ueberhaupt hat - Staging wird bei jedem Merge deployt, Produktion separat. Sonst tritt der Fehler beim naechsten Betrieb mit Luecke wieder auf. (2) Dieselbe Luecke steckt auch in der Sandbox bei ALIBABA; dort schadet sie nicht, weil der Build den Fix hat. - Das neue Onboarding-Werkzeug schreibt immer alle sieben Tage, ueber diesen Weg kann die Luecke nicht mehr entstehen. - SCHRITT 2 (Sandbox-Buchungsverkehr) wartet auf Kais' Go plus die Booking-Server-Zugangsdaten, weil das Werkzeug echte Buchungen anlegt und storniert. ## RwG SCHRITT 2 ANGEHALTEN vor der Ausfuehrung (12:50 CEST, Kais "go") - Kais gab go fuer den Sandbox-Buchungsverkehr. VOR dem Start geprueft, ob Nebenwirkungen entstehen - Memory deploy-poll-marker-must-be-side-effect-free ("3 unnoetige Testreservierungs-Mails ans Kunden-Restaurant"). - BEFUND 1, MAIL AN DEN WIRT: booking-server.service.ts:186 ruft _reservationUtilsService.notifyNewReservation(entity). utils.service.ts:88 ruft _emailService.notifyEvent(). email.service.ts:57-58 sendet BEIDES: sendGuestEmail UND sendOwnerEmail. Der Owner bekommt die Mail an settings.restaurant.email. Beim Sandbox-Durrani (3921b1d3-...) ist das info+durrani@kadicon.de, und Kais hat bestaetigt, dass diese Aliasse an die Laeden weiterleiten. Ein Werkzeuglauf erzeugt Buchung + Aenderung + Storno = ca. 3 Owner-Mails. Zehn Laeufe waeren ca. 30 Mails "Neue Reservierung" an das echte Restaurant Durrani. NICHT ausgefuehrt. - BEFUND 2, METHODENZWEIFEL: Das Werkzeug ruft unseren EIGENEN Server direkt auf (SANDBOX_BASE_URL = https://api.dev.kadicon.de/api). Googles Zaehler misst vermutlich den Verkehr, den GOOGLE zu uns schickt. Indiz fuer die Richtungsfrage: Beim RTU-Punkt ist die Richtung eindeutig partner->Google ("you only sent 0 out of 10"). Wenn der Zweifel stimmt, kosten die 30 Mails nicht nur Reputation, sondern bringen auch nichts. - VORSCHLAG an Kais, zwei kleine Schritte statt einem grossen: (1) Eine kadicon.de-Adresse nennen, die NICHT weitergeleitet wird. Damit lege ich per Onboarding-Werkzeug einen eigenen Sandbox-Testbetrieb an; darauf kann beliebig oft getestet werden, ohne dass ein Wirt etwas merkt. (2) EINE echte Testbuchung ueber den Link "RwG - E2E" (Front end) in der Sandbox-Inventory-Zeile. Danach pruefen, ob Googles Zaehler von 1 auf 2 springt. Klaert in fuenf Minuten, welcher Weg zaehlt, und kostet genau eine Mail. - Erst danach die 20 Anfragen fahren. ## RwG GROSSER FUND: Durranis Google-Eintrag gehoert buchungsseitig DISH (12:58 CEST) - Kais oeffnete Durranis Google-Buchungsseite (google.com/maps/reserve/v/dine/c/HCesr_4cXqY, PRODUKTIONS-Oberflaeche) und machte eine Testbuchung. - BEFUND: Auf der Buchungsseite steht "Anfragen zu Buchungszeiten erfolgen ueber den Partner: DISH" und in der Bestaetigung "In Zusammenarbeit mit DISH". Der Eintrag hat also bereits einen Buchungspartner, einen Wettbewerber. - TRAGWEITE: Erklaert Durranis Dauerstatus "Processing" womoeglich besser als alles andere. Selbst mit freigeschalteter Anbindung wuerde Google nicht auf KADiCon umschalten, solange DISH hinterlegt ist. Das ist keine technische Frage, das muss ueber den Wirt oder Google geklaert werden. - ZEITKRITISCH GEMELDET: Kais hat dabei eine ECHTE Reservierung erzeugt (heute 17:30, 2 Personen, Bestaetigung an aseckzai@gmail.com). Der Laden haelt einen Tisch frei. Zur Stornierung aufgefordert. - ZERTIFIKATSFRAGE: Kais wurde von reserve-partnerdev.sandbox.google.com nach einem Client-Zertifikat gefragt; angeboten wurden drei BMW-GERAETEZERTIFIKATE (MS-Organization-Access, MDMIdentity, AwVPNDeviceRoot bmw-uem-cn.awmdm.com/bmw.corp). Klare Antwort: KEINS, abbrechen. BMW-Gerätezertifikate haben auf einem Google-Server nichts verloren und authentifizieren dort auch nicht. Wenn die Seite dann nicht laedt, muss sein Google-Konto fuer die Partner-Sandbox freigeschaltet sein. - ZUR AUTOMATISIERBARKEIT: Die Buchungen laufen ueber Google-Webseiten mit angemeldetem Google-Konto. Ich habe weder Browsersteuerung noch Google-Sitzung. Das bleibt bei Kais. - Kais nannte kais@kadicon.de als NICHT weitergeleitete Adresse. Damit kann ich einen Sandbox-Testbetrieb anlegen und das E2E-Werkzeug beliebig oft laufen lassen, ohne dass ein Wirt Mails bekommt. Angeboten, wartet auf sein Ja. - Sandbox-Links liegen vor: Bistro Antep ZdIsrt6jHi8, Apetito Grill Apolda HIEq0mP5jhc (beide reserve-partnerdev.sandbox.google.com). ## RwG: Testbetrieb blockiert durch SES-Fehler, dafuer E2E-Lauf komplett gruen (13:06 CEST) - Kais gab kais@kadicon.de frei. POST /api/auth/verify auf STAGING -> HTTP 500. - URSACHE aus dem Staging-Log (den ich dort im Gegensatz zur Produktion habe): backend-staging-task-role fehlt ses:SendRawEmail auf identity/kadicon.de. SESv2ServiceException / AccessDeniedException. - BEFUND B9: Staging verschickt GAR KEINE Mails. Keine Bestaetigungsmails, keine Reservierungsmails an Gast oder Wirt, keine Erinnerungen. Vermutete Ursache: Commit 8cd046cd "staging ECS task role for backend (drop static AWS keys on staging)" - Rolle eingefuehrt, SES-Rechte nicht mituebertragen. - FOLGE 1: Der Sandbox-Testbetrieb laesst sich nicht anlegen, weil der Verifikations-Token nur per Mail entsteht. - FOLGE 2, ehrlich zu benennen: Meine Warnung vor 30 Mails an den Wirt war im Prinzip richtig, aber im JETZIGEN Zustand kann Staging keine Mail verschicken. Das ist Glueck, keine Absicherung - nach dem SES-Fix gilt die Warnung wieder. - DESHALB EINEN E2E-LAUF GEFAHREN (nicht zehn) gegen Durranis Sandbox-Merchant. ALLE 11 SCHRITTE BESTANDEN: HealthCheck, BatchAvailabilityLookup, CreateBooking, CreateBooking-Idempotenz, GetBookingStatus vor Aenderung, UpdateBooking (Aenderung), GetBookingStatus danach, UpdateBooking (Storno), GetBookingStatus CANCELED, wiederholtes Storno idempotent, BatchAvailabilityLookup zeigt den Slot wieder frei. Unser Booking-Server verhaelt sich also korrekt. - Zugangsdaten aus der Staging-Aufgabendefinition gelesen, nicht ausgegeben, danach verworfen. - NAECHSTER SCHRITT, das entscheidende Experiment: Kais prueft im E2E-Onboarding-Plan, ob der Zaehler bei "BatchAvailabilityLookup ready in Sandbox" von 1 hochgeht. Steigt er, zaehlt unser eigenes Werkzeug und ich fahre die restlichen Laeufe. Bleibt er bei 1, muss der Verkehr von Google kommen - und dann ist der Weg ueber die Sandbox-Buchungsseiten noetig, die bei Kais aber 404 liefern. - NEBENBEFUND aus Kais' Screenshot: Der Sandbox-Link fuer Apetito Grill Apolda (reserve-partnerdev.sandbox.google.com/.../HIEq0mP5jhc) liefert 404. Passt zur abgeschalteten Anbindung. ## RwG: Booking-Server-Dashboard beantwortet die Zaehlerfrage - SACKGASSE (13:13 CEST) - Kais schickte das Sandbox-Dashboard "Booking Server Endpoint Success / Failure Counts" und "Average Latency". - BEFUND: Genau EINE Anfrage jemals - BatchAvailabilityLookup Success Count 1, Datum 2026-08-29. Alle anderen Spalten leer. "Async vs. Sync Bookings": keine Daten. "CreateBooking with different confirmation mode": leer. - BEWEIS DER RICHTUNG: Google zeigt fuer diese Anfrage eine LATENZ von ca. 0,58 s. Eine Antwortzeit kann nur messen, wer die Anfrage selbst geschickt hat. Also kam sie VON Google. - FOLGERUNG: Unser eigenes E2E-Werkzeug zaehlt NICHT, weil es unseren Server direkt aufruft. Mein Verdacht von 12:50 war richtig, und es war richtig, nicht dreissig Laeufe zu fahren. Endgueltige Bestaetigung nach dem naechsten 30-Minuten-Refresh (mein Lauf war 11:06 UTC). - DIE SACKGASSE, sauber benannt: Anbindung abgeschaltet -> weil Meilensteine fehlen -> Meilensteine brauchen Buchungsverkehr VON Google -> der laeuft ueber Googles Buchungsseiten -> die liefern 404 (Apetito) oder verlangen ein Client-Zertifikat (Bistro Antep) -> weil die Anbindung abgeschaltet ist. Mit Code nicht aufloesbar. - ZERTIFIKAT NEU EINGEORDNET: Die Client-Zertifikatsabfrage von reserve-partnerdev.sandbox.google.com ist keine Stoerung, sondern die Zugangskontrolle fuer Partner-Sandboxen. KADiCon hat dieses Zertifikat offenbar nicht. - EINZIGER WEG: Google-Support, Fallnummer 05341814 vom 20.05.2026 existiert bereits. - ANGEBOTEN: Ich schreibe die Support-Anfrage auf Englisch, mit Partner-ID, Stand aller acht Meilensteine, der Sackgasse und drei konkreten Fragen (Zugang zur Partner-Sandbox, Wiedereinschaltung, wie der Abnahme-Buchungsverkehr erzeugt werden soll). Wartet auf Kais' Ja. ## RwG: Vollstaendige Vorgeschichte aus Googles Mails - die Zahl ist 25 (13:17 CEST) - Kais schickte fuenf Mails von Reserve with Google. Damit ist die Abschaltung vollstaendig erklaert: ``` 02.07. [05444607] Kimberly "decreased drastically from 35 to 1" 06.07. [05449191] Shiva Nachfrage 08.07. Pranay Nachfrage 21.07. [05487612] Donna "We have temporarily disabled your integration" Failure: Providing 1 merchant spaeter (automatisch) "We haven't received a feed from you in over 36 hours" ``` - KERNBEDINGUNG, in JEDER Mail wiederholt: "no fewer than 25" Produktionsbetriebe, die echten, von Maps erkennbaren Standorten entsprechen. Grund laut Google: Die Produktionsumgebung matcht gegen Google-Maps-Daten, und sie wollen Matching und Buchungsablauf ausreichend testen koennen. - WIR HABEN 23. Eine Wiedereinschaltungsbitte wuerde an exakt demselben Kriterium scheitern wie im Juli. Das ist der wichtigste Befund des Vormittags. - EINTRITTSKARTE ist Donnas Schlusssatz: "When you are confident these issues have been resolved, please contact us to confirm." - WEG ZU 25: Izmir Kebap Haus und Grill & Doener Haus by Theo aufschalten (23 + 2 = 25). Beide haben einen echten, OPERATIONAL gefuehrten Google-Eintrag mit Bewertungen (15 bzw. 23), Place-IDs bereits ermittelt: ChIJMZU-BQC3oEcRO1BnNJJOkZU und ChIJUQH5VgB9vkcRDQztf55d9A8. Ihr Sandbox-Status "Disabled" betrifft die Buchbarkeit, nicht die ANZAHL - Google verlangt echte Standorte, und das sind sie. - ANGEFORDERT von Kais: Telefonnummer und Tischplan fuer Izmir und Theo (beide waren aus der Eingabeliste herausgenommen). Danach zwei Bestaetigungsmails, Links, zehn Minuten. - WARNUNG mitgegeben: 25 ist die Untergrenze ohne Reserve. Faellt spaeter ein Betrieb aus, sind wir wieder darunter. Weitere Vertragskunden mit aufnehmen, wenn vorhanden. - KAIS' BEGRUENDUNG fuer den Rueckgang (fuer die Mail uebernommen): Schwierigkeiten mit den Zahlungsmoeglichkeiten, deshalb Reduzierung, inzwischen geloest. - EIGENE NEBENBEOBACHTUNG, NICHT in die Google-Mail geschrieben: Durranis googleReservations-Schluessel war ABWESEND, nicht false. Das ist die Signatur des Speicherfehlers B1, nicht die eines bewussten Ausschaltens. Moeglich, dass der Bug beim Rueckgang von 35 auf 1 mitgewirkt hat. Kais' geschaeftliche Begruendung bleibt massgeblich, das ist seine Sache. - LIEFERUNG: support-mail-entwurf.md (TG 11381/11382), Kopie im Vault. Englisch, freundlich, mit Fallnummern, Begruendung des Rueckgangs, Aufzaehlung des Wiederaufbaus, Feed-Nachweis, Bitte um Wiedereinschaltung und drei Fragen (Sandbox-Zugang, Erzeugung des Abnahme-Buchungsverkehrs, Umgang mit einem Eintrag der bereits einem anderen Partner gehoert - DISH-Fall, bewusst ohne Namensnennung). - Im Entwurf steht oben eine Warnung, welche zwei Aussagen erst nach dem Erreichen von 25 und nach dem Availability-Lauf am 07.09. zutreffen. ## RwG: Kais entscheidet gegen meine Empfehlung, Entwurf angepasst (13:22 CEST) - Kais: "25 ist nur eine Richtgroesse, es geht auch mit weniger. Wir behalten die 23." - Einwand EINMAL sachlich wiederholt (Google schreibt viermal woertlich "no fewer than 25", die Abschaltmail fuehrt es als Failure), dann seine Entscheidung akzeptiert. Er kennt den Kontakt, ich nicht. - ENTWURF UMGEBAUT statt nur die Zahl zu tauschen: Die 23 wird offen genannt und Googles EIGENES Angebot aufgegriffen, das in zwei der Mails steht: "If you are unable to provide these merchants, please let us know the reason so we can consult with our team on the appropriate next steps." Neue Bitte: Wir haben 23 echte Vertragskunden mit von Maps erkannten Standorten. Reicht das zur Wiedereinschaltung, oder sollen wir uns erst bei 25 melden? Lieber fragen als raten. Vorteil: ehrlich, nutzt Googles eigene Einladung, und im schlechtesten Fall bekommen wir eine verbindliche Antwort statt einer Vermutung. - OFFEN vor dem Senden: nur noch der Satz zum Availability-Feed. Wird morgen frueh wahr, wenn der Lauf durchgeht. Kais gebeten, bis dahin zu warten. ## RwG: Sendeweg geklaert + eigener Rat korrigiert (13:34 CEST) - Kais fragte: per E-Mail oder ueber Help & Support - Cases? Screenshot zeigt: OPEN-Liste LEER (0 of 0), die alten Faelle liegen unter RESOLVED. - ANTWORT aus Googles eigenen Mails: "If your case is closed, please use the Follow Up On Case button in the Actions Center case view." Weg: Help & Support > Cases > Reiter RESOLVED > Suche 05487612 > Fall oeffnen > "Follow Up On Case". 05487612 ist der richtige Faden (Donnas Abschaltmail mit "When you are confident these issues have been resolved, please contact us to confirm"). Wir antworten damit exakt auf die Aufforderung, die den Fall geschlossen hat. - KEIN neuer Fall, solange der Knopf existiert - verliert die Vorgeschichte und landet bei jemand anderem. Fallback nur wenn der Knopf fehlt: Box "How can we help?" mit "Follow-up on cases 05487612, 05449191 and 05444607" in der ersten Zeile. - NICHT per Mail: reserve-partners-support@google.com ist eine unbearbeitete Absenderadresse. - EIGENEN RAT KORRIGIERT: Ich hatte 12 Minuten zuvor geraten, bis morgen zu warten. Beim erneuten Lesen des Satzes ("is expected to upload normally from the next daily run onwards") ist das eine Erwartung, keine Behauptung, und heute bereits korrekt. Neue Empfehlung: HEUTE senden. Googles Support brauchte im Juli ueber zwei Wochen fuer drei Mails; der Tag Vorsprung wiegt mehr als ein Beweis, den wir beim Nachfassen liefern koennen. - Zugesagt: Wenn der Availability-Feed morgen laeuft, liefere ich einen Zweizeiler zum Nachhaengen. - EIGENER FEHLER: Erste Telegram-Nachricht wurde abgelehnt, weil der Bindestrich in "Follow-up" ausserhalb eines Codeblocks nicht maskiert war. Zum wiederholten Mal dasselbe Muster (Memory telegram-escape-blind-spot-bold-headers). Behoben, indem die Zeile in einen Codeblock gewandert ist. ## RwG: Support-Formular ausgefuellt beraten (13:38 CEST) - Kais hat "Follow Up On Case" gefunden, Titel vorbelegt mit "Follow up on case 'KADiCon + Reserve with Google Inte...'". Fragte nach den beiden Pflicht-Auswahlfeldern. - EMPFEHLUNG: Category "Technical issue", Reason "Integration is down". Beschreibt exakt den Zustand und leitet an das Team, das wieder einschalten kann. - BEGRUENDET ABGERATEN: "Policy question" (landet bei den Richtlinien-Leuten, die schalten nichts ein), "Takedown/Restriction Measures" (meint Inhalte und Rechtliches), "Feed question" (zu klein gedacht, der Feed laeuft ja). - WICHTIGES DETAIL GEFUNDEN: Im Formularfeld Email Address stand aseckzai@gmail.com. Die gesamte bisherige Google-Korrespondenz lief aber ueber info@kadicon.de (alle vier Mails waren an diese Adresse gerichtet). Kais gebeten, info@kadicon.de einzutragen, damit der Vorgang zusammenbleibt und die Antwort dort landet, wo die Vorgeschichte liegt. - Zusatz fuer die erste Zeile des Textfelds vorgegeben: Partner ID 20002024 und die drei Fallnummern. ## RwG: Support-Fall 05599496 ist offen (13:42 CEST) - Kais hat den Follow-up abgeschickt. Issue Id 05599496, Betreff "Follow up on case 'KADiCon + Reserve with Google Integration Disabled'-05487612", Status OPEN, Last Update 06.09.2026. Sauber mit dem alten Fall verknuepft. - ERWARTUNG gesetzt: Im Juli brauchte Google fuer drei automatische Nachfassungen gute zwei Wochen. Eine echte Bearbeitung dauert Tage. Wenn bis Mitte naechster Woche nichts kommt, nachfassen - der Fall ist offen. - STAND: Unsere Seite fertig und geprueft, Feeds laufen taeglich fehlerfrei, die Freischaltung liegt bei Google. - ZUGESAGT fuer morgen frueh: Pruefung des Availability-Feeds nach dem 05:00-UTC-Lauf. Das ist der Beweis fuer die Diagnose. Bei Erfolg Zweizeiler zum Nachhaengen an den Fall. - WEITER OFFEN bei anderen: PR 279 (ungemergt), SES-Berechtigung auf Staging, Produktions-Logzugriff, DISH als Buchungspartner bei Durrani, Izmir und Theo zurueckgestellt. ## PR 279 gemergt, SES-Fix als PR 280 nachgelegt (13:50 CEST) - Kais hat PR 279 gemergt (Merge-Commit 8a874118 auf main). Der Speicherfehler ist damit im Code behoben; der Staging-Deploy laeuft ueber merge.yml automatisch. - KAIS' KORREKTUR aufgenommen: KADiCon hat nichts mit adesso zu tun, adesso gehoert nur zu SupplierPulse. Als Memory kadicon-und-supplierpulse-getrennt gespeichert, ACTIVE_TASK korrigiert. - SES-FEHLER NICHT NUR BESCHRIEBEN, SONDERN BEHOBEN: PR 280 https://github.com/KADiCon-UG/kadicon/pull/280 - URSACHE steht im eigenen Commit-Text von 8cd046cd: Die Rolle wurde mit "SES SendEmail" angelegt. infra/src/modules/ecs/main.tf Zeile 72 hatte Action = ["ses:SendEmail"]. Der Mailer verschickt aber eine vollstaendige MIME-Nachricht, und die autorisiert SES als ses:SendRawEmail. Eine Aktion daneben, und Staging verschickt gar nichts. - FIX: Action = ["ses:SendEmail", "ses:SendRawEmail"]. Klammer- und Anfuehrungszeichen-Bilanz der Datei geprueft (97/97, 23/23). Terraform ist lokal nicht installiert, deshalb keine fmt/validate-Pruefung - im PR offengelegt. - Produktion nicht betroffen: task_role_arn ist dort null, die Rolle wird nur fuer Staging angelegt (count = var.stage == "staging"). - WICHTIGER HAKEN im PR und an Kais gemeldet: Terraform wird NICHT von der CI angewendet. .github/actions/deploy fuehrt tools/deploy/staging.sh aus, kein terraform apply. Nach dem Merge muss jemand einmal "npx nx run infra:apply" laufen lassen. Danach pruefe ich mit einem Aufruf gegen /api/auth/verify (204 statt 500). - TRAGWEITE benannt: Seit 31.08. kann in Staging kein Betrieb mehr angelegt werden (Bestaetigungsmail kommt nie an), und Reservierungsmails an Gast und Wirt gehen nicht raus. ## Stand nach dem Vormittag (13:52 CEST) - PR 279 und PR 280 beide gemergt. Zwei Fehler gefunden, zwei behoben. - EINZIGE offene Handlung bei Kais: `npx nx run infra:apply` fuer Staging, damit der SES-Fix wirkt (die CI wendet kein Terraform an). Danach pruefe ich /api/auth/verify. - Nachgehakt: Stornierung der Testbuchung bei Durrani (heute 17:30, 2 Personen). Kais hatte darauf noch nicht geantwortet. - WARTET AUF GOOGLE: Fall 05599496, offen seit heute. Nachfassen Mitte naechster Woche, falls still. - ICH UEBERNEHME: morgen frueh nach dem 05:00-UTC-Lauf die Pruefung des Availability-Feeds (Beweis der Diagnose); nach Kais' Apply die Pruefung des Mailversands auf Staging. - DARF LIEGEN BLEIBEN: Passwoerter (kadicon123 auf 22 Produktionskonten), doppelter Durrani 22130b68 (abgeschaltet, nur ueber die Datenbank loeschbar), Izmir und Theo (fuer 25 fehlen Telefon und Tischplan), Durrani/DISH (Gespraech mit dem Wirt, nicht technisch). ## Terraform-Weg zurueckgenommen, Konsolenweg empfohlen (13:55 CEST) - Kais fragte "was genau machen?" und zeigte die GitHub-Repo-Seite. Er wollte den Apply offenbar dort ausfuehren - geht nicht, das braucht eine lokale Kommandozeile. - VOR DER ANLEITUNG GEPRUEFT, was `nx run infra:apply` wirklich tut. infra/src/Makefile: `terraform apply -var-file=./envs/${STAGE}.tfvars`. - BEFUND: Der Ordner infra/src/envs/ EXISTIERT NICHT im Repository. .gitignore Zeile 71 schliesst *.tfvars aus, Grund laut Commit-Historie "security(KAR-720): remove committed *.tfvars with live secrets". Die Datei enthaelt laut variables.tf unter anderem postgres_password, stripe, google, firebase, datadog_api_key. - DESHALB EIGENE EMPFEHLUNG ZURUECKGENOMMEN: Ohne die korrekte tfvars fasst terraform apply den GESAMTEN Staging-Stack an, Datenbank inklusive. Das Risiko steht in keinem Verhaeltnis zu einer fehlenden IAM-Aktion. Ich hatte den Weg vorher empfohlen, ohne ihn zu Ende geprueft zu haben. - STATTDESSEN Konsolenweg mit exakten Namen (aus der Terraform und per aws iam list-role-policies verifiziert): IAM > Rollen > backend-staging-task-role > Inline-Richtlinie backend-staging-task-policy > JSON > "Action": ["ses:SendEmail"] ersetzen durch ["ses:SendEmail", "ses:SendRawEmail"]. - KEIN PFUSCH, weil PR 280 gemergt ist: Code und Konsole sagen dasselbe, ein spaeterer Apply schreibt den Zustand fest statt ihn zu ueberschreiben. ## SES: erster Fix war unvollstaendig, zweite Schicht gefunden (14:03-14:06 CEST) - Kais hat die Richtlinie in der Konsole aktualisiert (nach einem Tippfehler mit doppeltem Anfuehrungszeichen, den ich im eingefuegten JSON gefunden und durch die vollstaendige Fassung ersetzt habe). - GEGENGEPRUEFT statt geglaubt: aws iam get-role-policy zeigte die korrekte Action-Liste. Der Aufruf gegen /api/auth/verify lieferte aber weiter HTTP 500. - LOG GELESEN statt geraten: Die Fehlermeldung hatte sich GEAENDERT. vorher: ... on resource .../identity/kadicon.de jetzt: ... on resource .../configuration-set/my-first-configuration-set - BEFUND: SES autorisiert Identitaet und Configuration Set GETRENNT. Das Konto verschickt ueber ein Standard-Set, das auf der SES-Seite an der Identitaet haengt; der Code benennt es nirgends (apps/backend/src/app/global/email/email.module.ts setzt nur SendEmailCommand, kein Set). Deshalb war es in der Richtlinie unsichtbar und mir beim ersten Mal durchgegangen. - Eigene SES-Leserechte fehlen (ses:GetEmailIdentity, ses:ListConfigurationSets beide AccessDenied), der Name kam aus der Fehlermeldung. - KAIS die vollstaendige neue Richtlinie geschickt (Resource als Liste mit beiden ARNs). - TERRAFORM NACHGEZOGEN: PR 281 https://github.com/KADiCon-UG/kadicon/pull/281. Resource als Liste, neue Modul-Variable ses_configuration_set mit Default "my-first-configuration-set", damit keine .tfvars angefasst werden muss. Klammernbilanz geprueft (99/99, 24/24). - Stand 14:05: In AWS steht bei Resource noch die Identitaet allein, Kais hat also noch nicht gespeichert. Warte auf seinen Bescheid. - MUSTER festgehalten (Memory fix-can-unmask-deeper-layer-failure): Ein Fix legt die naechste Schicht frei, die Fehlermeldung verschwindet nicht, sie wandert. Nach jedem Berechtigungs-Fix denselben Aufruf nochmal fahren und die Meldung LESEN. ## SES BEHOBEN UND VERIFIZIERT (14:06-14:07 CEST) - Kais hat die vollstaendige Richtlinie gespeichert, PR 281 gemergt. - GEGENGEPRUEFT auf drei Ebenen statt auf sein "updated" zu vertrauen: 1. aws iam get-role-policy: beide Aktionen (SendEmail, SendRawEmail), beide Ressourcen (identity + configuration-set). 2. Drei Versendungen gegen /api/auth/verify: 14:06:36, ~14:07, 14:07:06 - alle HTTP 204. 3. Log-Fenster ueber 5 Minuten: nur zwei Fehler, Zeitstempel 12:03:29 und 12:05:22 UTC = 14:03 und 14:05 CEST, also MEINE eigenen Versuche VOR dem Speichern. Danach nichts. - Eigener kleiner Ausrutscher: Im Pruefskript habe ich "CEST" an UTC-Zeiten geschrieben, weil der Host UTC laeuft. Selbst bemerkt und beim Auswerten korrekt umgerechnet. - Drei Testmails liegen in KADiCons Postfach (kais@, info+rwgtest@, info+rwgprobe2@). Kais darauf hingewiesen, dass er sie loeschen kann. - WICHTIGE FOLGE, an Kais gemeldet: Der unbeabsichtigte Schutz ist weg. Testbuchungen in der Sandbox schicken ab sofort wieder ECHTE Mails an die Wirte. Vor weiteren Buchungstests braucht es einen Testbetrieb mit nicht weiterleitender Adresse - jetzt anlegbar, weil der Versand wieder geht. - EIGENTLICHER GEWINN: Seit 31.08. konnte in Staging kein Betrieb mehr angelegt werden, weil die Bestaetigungsmail nie ankam. Still kaputt, ohne dass es jemand gemerkt haette. ## Bilanz des Tages (Stand 14:10 CEST) Drei Pull Requests, alle gemergt: - 279 settings save() liest die Zeile wieder vollstaendig (Datenverlust bei jedem Speichern der Restaurant-Einstellungen) - 280 ses:SendRawEmail auf der Staging-Task-Rolle - 281 Configuration Set als zweite SES-Ressource Dazu: Availability-Feed-Ursache gefunden und Daten korrigiert (fehlender Sonntag bei ALIBABA), Google-Support-Fall 05599496 eroeffnet, Onboarding-Werkzeug gebaut, neun Produktbefunde dokumentiert. ## Abschluss (14:15 CEST) - Kais bestaetigt: Testmails angekommen und geloescht (durchgaengiger Beweis, nicht nur SES-Annahme), Testbuchung bei Durrani storniert. - Damit ist von Kais' Seite nichts mehr offen. Der Rest liegt bei Google (Fall 05599496). - ZUGESAGT fuer morgen frueh: Pruefung des Availability-Feeds nach dem 05:00-UTC-Lauf, Meldung in BEIDE Richtungen - auch wenn sie meine Diagnose widerlegt. ## Kais bietet vollen AWS-Zugriff an - abgelehnt (14:15 CEST) - Frage: "Kann ich Dir vollen AWS zugriff geben, damit du die sachen fuer mich autonom erledigen kannst?" - ABGELEHNT, mit Begruendung statt aus Reflex: Im Konto liegen Produktionsdatenbank mit echten Gaestedaten, Stripe-Schluessel, Googles Service-Account-Key, SFTP-Schluessel. Am selben Tag hatte mein erster Schreibvorgang bei ALIBABA die Place-ID geloescht - reparabel nur, weil ich die Werte vorher gelesen hatte. Mit Adminrechten waere der naechste solche Fehler nicht auf einen Betrieb begrenzt. Dazu: Meine Zugangsdaten liegen als Datei auf dem Server, was ich darf darf auch wer den Server uebernimmt. - STATTDESSEN konkrete, rein LESENDE Liste vorgeschlagen (zweite Richtlinie an aria-automation): * CloudWatch Logs lesen fuer die Produktion, oder ein funktionierender Datadog-Schluessel * AppConfig lesen fuer das Produktionsprofil aqc7vab * SES lesen (GetEmailIdentity, ListConfigurationSets) - AUSDRUECKLICH NICHT gewollt: Schreibrechte auf Produktionsdaten, IAM-Schreibrechte, Secrets Manager. Bei so etwas ist es richtig, dass Kais selbst klickt. - EHRLICHE SCHLUSSBILANZ mitgeliefert: Der Engpass des Tages war nicht AWS, sondern Googles Weboberflaechen (angemeldetes Konto noetig) und Entscheidungen, die Kais gehoeren. Mehr Rechte haetten den Vormittag schneller gemacht, aber nicht anders ausgehen lassen. - Als Memory aws-rechte-lesend-statt-voll gesichert. ## Datadog-Raetsel geloest + Leserechte-Richtlinie geliefert (14:17 CEST) - Kais will die drei Leserechte einrichten. VOR der Anleitung noch etwas geprueft, das die Datadog-Frage sofort klaerte. - BEFUND: Der Datadog-API-Schluessel, mit dem die PRODUKTION ihre Logs hinschickt (logConfiguration.options.apikey in backend-production:8), ist ein ANDERER als der in /home/aria/datadog-runtime.env. Verglichen ueber sha256-Praefixe, keine Werte ausgegeben: aa8ba091... gegen 431a4b8a..., beide 32 Zeichen. - ERKLAERT die null Treffer auf JEDE Abfrage inklusive "*": Ich habe in eine andere Datadog-Organisation geschaut, dort liegt schlicht nichts. Das war also weder ein Rechte- noch ein Retention-Problem. - BENOETIGT: API-Schluessel UND Application-Schluessel aus DER Organisation, in die die Logs laufen; der Application-Schluessel braucht Logs-Leserecht. - IAM-RICHTLINIE geliefert, fertig zum Einfuegen, Name aria-automation-readonly-diagnostics, drei Statements: LogsRead (Describe/Filter/Get/StartQuery/GetQueryResults), AppConfigRead (auf Anwendung 540vb0a und deren Unterressourcen), SESRead (GetEmailIdentity, ListEmailIdentities, ListConfigurationSets, GetConfigurationSet). Ausschliesslich lesend. - EHRLICH DAZU GESAGT: Der CloudWatch-Teil hilft der PRODUKTION nicht, weil dort nichts hinschreibt. Er ist fuer Staging sinnvoll und falls spaeter eine Produktionsgruppe entsteht. Die eigentliche Luecke schliesst der Datadog-Schluessel. ## Leserechte eingerichtet, sofort zwei Befunde (14:21 CEST) - Kais hat die Richtlinie aria-automation-only-read angelegt. Alle drei Bereiche sofort getestet: AppConfig Produktion, SES, CloudWatch - alle funktionieren. - BEFUND B10, sofortiger Ertrag: Das Produktionsprofil aqc7vab hat ZWEI gehostete Versionen, Unterschied ist genau eine Zeile. Version 1: google_feeds_upload_cron_schedule "0 0 5 * * *" (taeglich 05:00 UTC) Version 2: google_feeds_upload_cron_schedule "0 */10 * * * *" (ALLE ZEHN MINUTEN) Version 1 laeuft - geschlossen aus Googles Feed History (05.09. und 06.09. jeweils 05:00 UTC), NICHT aus AWS bestaetigt. RISIKO: Wer Version 2 ausrollt, laedt den kompletten Feed 144x taeglich zu Google hoch. Genau die Art Verhalten, die eine Anbindung abgeschaltet bekommt - waehrend wir um Wiedereinschaltung bitten. Kais empfohlen: loeschen oder auf 0 0 5 zuruecksetzen. - EIGENE AUSLASSUNG eingeraeumt: appconfig:ListDeployments fehlt in der Richtlinie, die ich Kais entworfen habe. Deshalb kann ich die ausgerollte Version nicht direkt sehen. Nachtrag vorgeschlagen (ListDeployments, GetDeployment). - BEFUND B11: SES-Leserecht bestaetigt die Diagnose von 14:03 unabhaengig. get-email-identity kadicon.de liefert ConfigurationSetName "my-first-configuration-set". Das Set haengt an der Identitaet, der Code benennt es nie - genau wie vermutet. ## Eigenen Befund B10 korrigiert, sobald ich die Ausrollungen sehen konnte (14:29 CEST) - Kais hat ListDeployments/GetDeployment ergaenzt. Sofort geprueft. - BESTAETIGT: Produktion laeuft auf Version 1 (Deployment Nr 9, 01.05.2026 10:33, COMPLETE). Mein Schluss aus den Feed-Zeiten war richtig, jetzt belegt statt geschlossen. - EIGENEN BEFUND ZURUECKGENOMMEN: Ich hatte Version 2 als "scharfe Mine" bezeichnet. Die Deployment-Historie zeigt das Gegenteil: Nr 6 V2 (06:32) -> Nr 7 V1 (06:46) -> Nr 8 V2 (10:17) -> Nr 9 V1 (10:33). Zweimal rein, wenige Minuten spaeter zurueck. Das ist ein FEED-AUSLOESER, kein Versehen, und beide Male sauber zurueckgesetzt. - BESONDERS AERGERLICH: Genau diese Technik habe ich am 03.09. selbst auf Staging verwendet (Nr 35 Version 10 = Ausloeser, Nr 36 Version 11 = Reset, beide 03.09. 12:10 und 12:17). Ich hatte das Muster vor Augen und habe es in der Produktion trotzdem nicht wiedererkannt, weil ich nur die Versionsinhalte sah und nicht ihre Verwendung. - LEHRE: Ein Konfigurationsstand ohne seine Aenderungshistorie laesst sich falsch lesen. Bevor ein abweichender Wert zur Warnung wird, die Historie ansehen - vielleicht ist die Abweichung ein Werkzeug und kein Fehler. - WAS BLEIBT, kleiner formuliert: Wird der Reset vergessen, laufen 144 Feeds taeglich. Die Versionen tragen keine Beschreibung, ein Hinweistext wuerde helfen. - NEBENBEFUND: Die Produktions-Konfiguration wurde seit 01.05.2026 nicht mehr veraendert, vier Monate. ## AWS-Kostenanalyse (14:35-14:45 CEST) - Kais: "Meine AWS Kosten sind sehr hoch fuer unser kleines Unternehmen. Wie koennen wir es reduzieren?" Screenshot Billing plus costs.csv (Maerz-August 2026). - KERNBEFUND: Die Kosten sind NICHT generell hoch, ein einziger Posten ist explodiert. ``` Monat Gesamt CloudWatch 2026-03 171.00 0.00 2026-04 180.98 0.00 2026-05 180.15 0.02 2026-06 207.58 28.03 2026-07 242.56 55.77 2026-08 240.32 53.56 ``` Alles andere (RDS 36, VPC 29, ECS 25, ELB 20, Cache 11, EC2 10) ist seit Maerz flach. Der komplette Anstieg von 171 auf 240 ist CloudWatch plus die mitlaufende Steuer. - URSACHE GEMESSEN statt geraten: GetMetricData-Aufrufe rund 800 pro Tag, sieben Tage konstant (798/798/802/800/796/799/798). Gleichmaessig verteilt = Poller, kein Mensch. Datadog ist im Konto aktiv (Sidecar in beiden ECS-Aufgaben, awsfirelens-Logweiterleitung). Die AWS-Anbindung von Datadog fragt CloudWatch periodisch ab, abgerechnet wird pro angefragter Metrik. - AUSGESCHLOSSEN: Container Insights (auf beiden Clustern disabled), eigene Metriken (alle Namensraeume AWS/*, kostenfrei), Alarme (0), Log-Speicher (8,8 GB = 0,26 USD). - ZEITPASSUNG stuetzt es: null bis Mai, halber Monat Juni, voll ab Juli. - ZWEITER BEFUND: VPC 29,79 USD sind fast vollstaendig oeffentliche IPv4-Adressen. 7 Schnittstellen x 0,005 USD/h x 730 h = 25,55 USD. Keine NAT-Gateways vorhanden. * Eine Elastic IP (18.153.167.91) ist GAR NICHT zugeordnet - 3,60 USD/Monat fuer nichts. * BEIDE Datenbanken haben PubliclyAccessible: true. Kostet zwei Adressen und ist eine offene Tuer; das Backend laeuft in derselben VPC. Sicherheitsbefund, nicht nur Kostenfrage. * ECS-Aufgaben mit assignPublicIp ENABLED sind hier NOETIG (kein NAT), ausdruecklich nicht anfassen - ein NAT-Gateway kostet mehr als die IPs. - EMPFEHLUNG nach Groesse: (1) Datadog-Anbindung auf gebrauchte Namensraeume eingrenzen, bis 45 USD, 15 Min. (2) Ungenutzte Elastic IP freigeben, 3,60 USD. (3) Datenbanken auf privat, 7 USD plus Sicherheitsgewinn. (4) Staging nachts abschalten, 15-20 USD. Realistisch von 240 auf rund 160. - EINSCHRAENKUNG offengelegt: Kein Cost-Explorer-Leserecht, die CloudWatch-Zuordnung ist begruendete Annahme, kein Beweis. Kais soll in Cost Explorer nach Usage Type gruppieren; steht EU-CW:Requests oben, ist es bestaetigt. - LIEFERUNG: aws-kosten-analyse.md (TG 11428/11429), Kopie im Vault. - NEBENBEI EINGEGANGEN, nicht bearbeitet: 260401_QAF_HICE_Aktuell.xlsx (gehoert zum QAF-Strang, nicht zu RwG). ## Kostenmassnahmen: Rechte und konkrete Schritte (14:41 CEST) - Kais bietet weitere Rechte an und fragt, was konkret umzusetzen ist. - COST EXPLORER angefordert (harmlos, rein lesend): ce:GetCostAndUsage, GetCostForecast, GetDimensionValues, GetTags, GetAnomalies, GetAnomalyMonitors. Damit kann ich die Rechnung kuenftig selbst aufschluesseln statt um Screenshots zu bitten. - SCHREIBRECHTE ERNEUT ABGELEHNT, konsistent zur Entscheidung von 14:15: Drei der vier Massnahmen sind Zwei-Minuten-Klicks, bei der Datenbank ist es richtig, dass ein Mensch draufschaut. rds:ModifyDBInstance waere fuer einen booleschen Wert voellig ueberdimensioniert. - ENTSCHEIDENDE RUECKFRAGE VOR DER BASTELANLEITUNG: Schaut ueberhaupt jemand in Datadog auf AWS-Metriken (Dashboards, Monitore)? Falls nein, kann die AWS-METRIK-INTEGRATION KOMPLETT ABGESCHALTET werden - volle 55 USD statt muehsamer Namensraum-Filter. Die Log-Weiterleitung laeuft getrennt und bleibt unberuehrt. Erst fragen, dann Anleitung schreiben. - SOFORT MOEGLICH: Elastic IP 18.153.167.91 freigeben (EC2 > Elastic IPs > Aktionen > freigeben). WARNUNG mitgegeben: Freigeben ist endgueltig, die Adresse ist danach weg; falls sie irgendwo als feste Adresse hinterlegt war (Partner, Freigabeliste), vorher pruefen. - DATENBANKEN getrennt behandeln: Vor dem Umstellen auf privat klaeren, wer sich von aussen verbindet (Kais mit einem DB-Werkzeug, Auswertungstools, der DMS-Dienst der im Konto laeuft). Sonst bricht es. ## KOSTENANALYSE KORRIGIERT - zweimal falsch gelegen (14:47-14:55 CEST) - Kais gab Cost-Explorer-Leserechte. Damit sofort die eigene Diagnose ueberprueft - und widerlegt. - FEHLER 1: Ich hatte die Datadog-AWS-Anbindung als Ursache der 55 USD benannt. Falsch. Cost Explorer nach USAGE_TYPE fuer August: EUC1-DataProcessing-Bytes 50,02 USD (93,4 %), EUC1-CW:GMD-Metrics 3,41 USD, Rest Cent-Betraege. Nach OPERATION: PutLogEvents. Also LOG-AUFNAHME, nicht Metrik-Abfrage. Datadogs Abfragen machen 3,41 USD aus, nicht 55. - FEHLER 2, schwerer: Das Problem ist SEIT DEM 31.08. BEHOBEN. Tagesverlauf der Gruppe /ecs/backend-staging-debug: 07.08. bis 30.08. konstant 2,73 GB/Tag, 31.08. noch 0,96 GB, ab 01.09. NULL. Ausloeser war Commit 8cd046cd vom 31.08. ("drop static AWS keys on staging"). Die rotierten statischen Schluessel verursachten laufend UnrecognizedClientException, das Backend protokollierte das in einer Dauerschleife. Derselbe Commit, der den Mailversand kaputt machte, sparte 50 USD im Monat. - UND ES STAND SCHON IN KAIS' ERSTEM SCREENSHOT: "Monat bisher 31,11 USD (-59 %)", "Prognose 157,37 USD (-35 %)". Ich hatte die Zahlen vor mir und habe sie gelesen, aber nicht gedeutet. - WEG ZUR WAHRHEIT: erst 800 GetMetricData-Aufrufe/Tag gemessen (richtig, aber irrelevant), dann Cost Explorer nach Nutzungsart (korrigierte die Zuordnung), dann IncomingBytes je Log-Gruppe ueber 30 Tage (66,57 GB, 34,3 Mio Ereignisse), dann Tagesverlauf (zeigte das Ende am 31.08.). Zwischendurch eine 7-Tage-Messung, die nur 3,69 GB zeigte - haette mich stutzig machen muessen. - KORREKTUR an Kais gemeldet und im Dokument aws-kosten-analyse.md als Kasten vorangestellt, alte Fassung als Beleg stehen gelassen. - WAS BLEIBT: September landet bei rund 155 statt 240. Restliche Hebel klein: ungenutzte Elastic IP 3,60 USD, Datenbanken auf privat 7 USD, Staging nachts aus 15-20 USD. Von 155 auf etwa 130. - Als Memory kostenbefund-erst-aus-der-abrechnung gesichert. ## Elastic IP freigegeben und gegengeprueft (14:57 CEST) - Kais sah in seiner Konsole keine Elastic IPs - falsche Region. Alle sechs liegen in eu-central-1 (Frankfurt), in us-east-1 gibt es keine. Ihm die vollstaendige Liste mit Zuordnungsstatus und die Allocation-ID der ungenutzten geschickt, plus die ausdrueckliche Warnung, die anderen fuenf in Ruhe zu lassen (Verwechslungsgefahr ist bei einer irreversiblen Aktion das eigentliche Risiko). - 18.153.167.91 (eipalloc-0a4dac6663df1e25a) freigegeben. - GEGENGEPRUEFT statt geglaubt: vorher 6 Adressen davon 1 ohne Zuordnung, nachher 5 Adressen davon 0 ohne Zuordnung. Die richtige ist weg, die fuenf anderen haengen alle noch. 3,60 USD/Monat gespart, nichts kaputt. ## TAGESBILANZ 06.09.2026 Drei Pull Requests, alle gemergt (279 Datenverlust beim Speichern, 280 ses:SendRawEmail, 281 SES-Configuration-Set). Ein Datenfehler behoben (fehlender Sonntag bei ALIBABA, blockierte den gesamten Availability-Feed). Google-Support-Fall 05599496 eroeffnet, Ursache der abgeschalteten Anbindung gefunden und belegt. Elf Produktbefunde dokumentiert (B1 bis B11). AWS-Leserechte eingerichtet, Kostenfrage geklaert (Anstieg war eine Fehlerschleife, seit 31.08. vorbei). Elastic IP freigegeben. DREI EIGENE FEHLDIAGNOSEN im Lauf des Tages korrigiert: Datadog als Kostenursache, AppConfig-Version 2 als "Mine", und die Annahme, der Produktions-Cron habe nicht gefeuert. Jedes Mal hat erst der Zugriff auf echte Daten die Korrektur gebracht. ## Datenbank-Zugriff geklaert, eigene Formulierung praezisiert (14:58 CEST) - Kais: "Keiner verbindet sich von Aussen zu dem Datenbank. Ausser Google, wenn die es brauchen." - MISSVERSTAENDNIS AUSGERAEUMT: Google verbindet sich NIE zur Datenbank. Google spricht ausschliesslich mit dem Booking-Server ueber HTTPS (Load Balancer, API). Was dahinter liegt, sieht Google nie. Die Datenbank kann vollstaendig privat sein. - EIGENE FORMULIERUNG ZURUECKGENOMMEN: Ich hatte von einer "offenen Tuer" gesprochen. Zu scharf. Die Sicherheitsgruppen sind eng: Port 5432 nur fuer 76.13.135.118/32 und fuer die interne Sicherheitsgruppe der ECS-Aufgaben. Die Datenbanken haengen NICHT im offenen Netz. Der oeffentliche Endpunkt ist trotzdem unnoetig und kostet 7 USD. - OFFENE FRAGE an Kais: Wem gehoert 76.13.135.118? Alte Entwickleradresse -> Regel raus. Seine eigene -> er verliert den Zugang. - VORBEHALT genannt: Zwei DMS-Replikationen im Konto, Log-Gruppen vorhanden aber leer. Ob sie sich auf die Datenbanken verbinden, kann ich ohne dms:DescribeReplications nicht pruefen. - VORGEHEN vorgeschlagen: erst main-db-staging auf privat, einen Tag beobachten, dann Produktion nachziehen. - Praezisierung in aws-kosten-analyse.md eingearbeitet. ## Kostenwache gebaut und scharf geschaltet (15:05 CEST) - Kais: "Ich weiss es nicht. Lassen wir es dann lieber. Beobachte die Kosten." - DATENBANK-UMSTELLUNG ABGESAGT, seine Entscheidung bestaetigt: Bei einer freigeschalteten Adresse, deren Besitzer niemand kennt, ist Nichtstun richtig. Sieben Dollar rechtfertigen es nicht, jemandem unbekannten den Zugang abzuschneiden. - WACHE GEBAUT statt "ok" zu sagen: /home/aria/projekte/aws-kostenwache/ (kostenwache.py, melde.sh, Kopie im Vault). * Holt Cost Explorer je Dienst, vergleicht mit demselben Zeitraum des VORMONATS (nicht mit dem Vormonat gesamt, das waere unfair). * Auffaellig = mehr als 25 % Zuwachs UND mehr als 5 USD absolut. Beide Bedingungen, damit kleine Posten mit grossen Prozentspruengen nicht laermen. * Schweigt im Normalfall. Montags kommt der Bericht IMMER - eine Wache, die nur bei Stoerung spricht, ist von einer toten Wache nicht zu unterscheiden (Memory change-only-watch-is-no-watch). - ZWEI DINGE BEIM BAUEN GELERNT: * Die Steuer wird als Klumpen gebucht, nicht taeglich. Im Zeitraumvergleich verzerrte sie die Hochrechnung massiv (186 statt 157). Jetzt herausgerechnet und getrennt ausgewiesen. * Danach trifft die Hochrechnung AWS' eigene Prognose auf einen Dollar: 156,82 gegen 157,37. Gute Validierung der Methode. - CRONTAB: taeglich 07:12 UTC (09:12 CEST), off-minute gewaehlt. VORHER/NACHHER geprueft, die bestehende http.server-Zeile ist unveraendert erhalten (1 vorher, 1 nachher). - MELDEWEG EINMAL ECHT GETESTET statt angenommen: sendMessage an Kais, Antwort ok. Er hat den Testbericht bekommen. ## GOOGLE ANTWORTET NOCH AM SELBEN TAG (20:07 CEST, Marlou, Fall 05599496) Drei Aussagen, zwei davon korrigieren mich: 1. MEILENSTEINE IRRELEVANT: "Since your integration has been already launched all previous Onboarding Milestones may be safely ignored." -> Der gesamte E2E-Onboarding-Plan (25 %, Buchungszaehler, RTU) gilt fuer NEUKUNDEN, nicht fuer eine bereits gelaunchte Anbindung. MEINE SACKGASSEN-ANALYSE VON 13:13 WAR FALSCH: Es gibt keinen Kreis aus "Anbindung aus -> Meilensteine fehlen -> Verkehr geht nicht". Der ganze Buchungsverkehr-Strang ist damit erledigt. Nachtraeglich gut, dass die 30 Testmails nicht rausgingen. 2. DISH IST KEIN HINDERNIS: "the system allows merchants to have multiple providers/partners. As long as you provide the availability for that merchant your integration should be enabled for them." -> Auch hier lag ich daneben; ich hatte DISH als moeglichen Blocker fuer Durrani vermutet. 3. Merchant-Zahl (23 statt 25) und der Sandbox-404 werden intern beraten. Keine Entscheidung, aber beides aufgenommen. Kais' Einschaetzung, dass 25 nur eine Richtgroesse ist, war damit naeher an der Wahrheit als meine "harte Bedingung". - ENTSCHEIDENDE FOLGE: "As long as you PROVIDE THE AVAILABILITY". Genau das tun wir nicht - der Availability-Feed hat in der Produktion nie hochgeladen. Der Fehler, den ich heute Vormittag als Nebenschauplatz behoben habe (fehlender Sonntag bei ALIBABA), ist damit zum HAUPTWEG geworden. Morgen 07:00 zeigt sich, ob er laeuft. - GOOGLE BRAUCHT eine Merchant-ID fuer den Partner-Konflikt. Antwort entworfen: support-antwort-2.md mit Durranis Kennung 4e22f973-36d5-4e8c-b8a3-c85a7b87cf10, Service-ID, Place-ID und Adresse. - IN DER ANTWORT DIE EIGENE URSACHE OFFENGELEGT statt nur "wir liefern ab morgen": Google sieht in den eigenen Feeds, dass monatelang nichts kam. Wer den eigenen Fehler benennt und die Behebung zeigt, wirkt verlaesslicher als jemand, der eine Luecke stillschweigend fuellt. - EMPFEHLUNG an Kais: erst MORGEN nach 07:00 senden, dann steht statt "wir erwarten" ein Nachweis mit Datum und Datensatzzahl. Ein Beleg schlaegt eine Ankuendigung. ## AVAILABILITY-FEED LAEUFT - Diagnose bestaetigt (20:32 CEST) - Kais wollte den Nachweis sofort statt morgen. Feed per AppConfig-Ausloeser getriggert: Deployment 10, Version 2 ("0 */10 * * * *"), gestartet 18:25:12 UTC, 100 % ausgerollt. - ERGEBNIS in der PRODUKTIONS-Feed-History: ``` 9/6/26 20:32 Availability Processing 1 Shard 9/6/26 20:31 Services Success 23 Datensaetze 9/6/26 20:30 Merchant Processing 1 Shard ``` - EINE AVAILABILITY-ZEILE IN DER PRODUKTION, ZUM ERSTEN MAL UEBERHAUPT. Vorher gab es dort nur Merchant und Services. Der Feed bricht also nicht mehr ab -> meine Diagnose von heute Vormittag (fehlender Sonntag bei ALIBABA brach die Generierung fuer ALLE ab) ist bestaetigt. - NOCH OFFEN: Zwei Zeilen stehen auf "Processing" und zeigen 0 records, auch der Merchant-Feed, der morgens immer 23 hatte. Die Zahlen fuellen sich erst nach der Verarbeitung. NICHT voreilig als Erfolg melden - entscheidend ist die Datensatzzahl bei Availability. Steht dort spaeter null, ist die Datei angekommen aber LEER, dann fehlt noch etwas. - KAIS ZUERST ZUM ZURUECKSTELLEN aufgefordert (Version 1), bevor wir weiterschauen. Wir haben, was wir brauchten; ein zweiter Lauf bringt nichts und Version 2 darf nicht ueber Nacht stehen bleiben. - Ironie des Tages: Der AppConfig-Ausloeser, den ich mittags faelschlich fuer eine vergessene Mine hielt, war jetzt das Mittel, mit dem wir zwoelf Stunden frueher Gewissheit bekommen haben. ## Ausloeser zurueckgestellt und verifiziert (20:40 CEST) - Kais brauchte Hilfe bei der Strategie-Auswahl: AppConfig.AllAtOnce (Quick), dieselbe wie beim Ausloesen. Die drei anderen rollen langsam aus, hier nur Wartezeit. - Deployment 11, Version 1, 18:40:21 UTC, 100 %. - GEGENGEPRUEFT, NICHT NUR DIE VERSIONSNUMMER GELESEN: Die aktive Konfiguration enthaelt wieder google_feeds_upload_cron_schedule = "0 0 5 * * *". Taeglich 05:00 UTC, Normalzustand. - Historie jetzt: Nr 11 V1 (18:40) / Nr 10 V2 (18:25) / Nr 9 V1 (01.05.). Dasselbe Ausloeser-Muster wie am 1. Mai, zum dritten Mal, sauber zurueckgesetzt. Gesamtdauer 15 Minuten. - OFFEN: die Datensatzzahl der Availability-Zeile von 20:32. Kais soll die Feed History neu laden. Grosse Zahl = Feed liefert, Marlous Bedingung erfuellt. Weiterhin null = Datei kam an, war aber leer, Abbruch behoben aber nichts drin. - Hinweis mitgegeben: Der Merchant-Feed stand bei "Processing" ebenfalls auf null, obwohl er morgens 23 hatte. Spricht dafuer, dass die Zahlen nur noch nicht gefuellt waren. ## Availability-Zeile da, aber 0 Datensaetze - noch kein Nachweis (20:43 CEST) ``` 20:42 Availability Processing 0 20:41 Services Success 23 20:40 Merchant Success 23 20:32 Availability Processing 0 20:31 Services Success 23 20:30 Merchant Success 23 ``` - GUT: Merchant und Services stehen jetzt auf Success mit 23, die Zahlen fuellen sich also wie vermutet. Und die Availability-Zeile EXISTIERT - der Abbruch ist behoben, das steht fest. - OFFEN: Availability haengt seit elf Minuten auf Processing mit 0 Datensaetzen, waehrend die anderen aus derselben Minute fertig sind. Kombination 1 Shard hochgeladen / 0 Datensaetze / 0 Fehler spricht dafuer, dass eine lesbare, aber LEERE Datei ankam. - Der Lauf um 20:40 war der angekuendigte Nachzuegler: Reset kam 21 Sekunden vor der Zehnerschritt-Marke an. - NICHT ALS NACHWEIS AN GOOGLE GESCHICKT. "Wir liefern Availability" waere bei einer leeren Datei eine Behauptung, die Marlou beim ersten Blick widerlegen kann. - ZWEI DINGE ANGEFORDERT: (1) Detailansicht der Availability-Zeile ueber den Pfeil. (2) WICHTIGER, als Gegenprobe: dieselbe Feed History in der SANDBOX. Dort laedt der Availability-Feed nachweislich ueber 118.000 Zeitfenster. Zeigt die Sandbox Success mit grosser Zahl, ist die Null in der Produktion echt. Zeigt sie ebenfalls Processing/0, stellt Google Availability-Feeds einfach so dar und die Produktion ist normal. - BEWUSSTE DISZIPLIN: Statt eine dritte plausible Erklaerung zu bauen, erst die funktionierende Seite danebenlegen. Genau das hatte ich heute zweimal versaeumt (Datadog-These, AppConfig-"Mine"). ## GEGENPROBE ENTSCHEIDET: "Processing / 0" ist kein Befund (20:46 CEST) - Detailansicht der Produktions-Zeile: Dateiname Availability_Feed_production_1788719523.json.gz, Zeitstempel = 06.09. 18:32:03 UTC, exakt unser Lauf. Issues (0), Errors 0, Warnings 0. Die Datei kam an, war lesbar, Google beanstandet nichts. - SANDBOX-GEGENPROBE (die Frage, die ich statt einer dritten Theorie gestellt habe): ``` 06.09. 7:02 Availability Processing 0 <- seit 13 Stunden 06.09. 7:01 Services Processing 0 06.09. 7:00 Merchant Processing 0 05.09. 7:02 Availability Success 118.260 04.09. 7:02 Availability Success 118.260 03.09. 7:02 Availability Processing 0 <- seit DREI TAGEN 03.09. 14:19 Availability Success 118.260 ``` - BEFUND: "Processing mit 0 records" ist ein ANZEIGEZUSTAND, kein Inhaltsproblem. In der Sandbox, wo nachweislich 118.260 Zeitfenster hochgeladen werden, stehen Zeilen tagelang so - die vom 03.09. bis heute. Auch Merchant und Services stehen dort heute noch auf Processing. - FOLGE: Unsere Produktions-Zeile ist in Ordnung. Der Availability-Feed laeuft wieder, meine Diagnose vom Vormittag ist bestaetigt, und die fehlende Zahl sagt nichts ueber den Inhalt. - FAST EINE DRITTE FEHLDIAGNOSE: "Leere Datei" klang plausibel und haette sich als Befund verkaufen lassen. Die Gegenprobe dauerte dreissig Sekunden und war eindeutig. Dritte Wiederholung derselben Lehre an einem Tag (Datadog-These, AppConfig-Mine, jetzt die leere Datei) - diesmal habe ich VORHER gefragt statt hinterher korrigiert. - VORSCHLAG an Kais: Im Brief an Google NICHT "118.000 Datensaetze" behaupten, sondern die DATEI mit Namen und Zeitstempel nennen. Marlou kann sie auf ihrer Seite nachschlagen. Ueberpruefbar, ohne etwas zu behaupten, was wir nicht sehen. ## Brief an Google auf selbstbewusst umgeschrieben (20:52 CEST) - Kais: "Wir sollen mutiger auftreten ggü Google. Wie können wir positiver dastehen?" Berechtigt, der erste Entwurf war geduckt. - GEAENDERT: Keine Entschuldigungen ("thank you for your patience", "sorry"), Reihenfolge gedreht (erst ihre Frage beantwortet, dann was wir gebaut haben, dann erst die Schwachstelle), und der Availability-Fund als Staerke gerahmt: eigener Fehler, selbst gefunden, behoben bevor Google fragt. - WAS TATSAECHLICH STARK IST und jetzt drinsteht: 23 echte Vertragskunden; jede Place-ID gegen die Places-API geprueft (establishment-Typ, PLZ-Abgleich, OPERATIONAL); kein Betrieb geht live ohne Nachweis, dass an jedem offenen Tag Zeitfenster entstehen; Booking-Server end-to-end verifiziert inkl. Idempotenz und Storno. Auch der Fund der falschen Place-ID (Strasse statt Restaurant) steht drin, weil er zeigt, dass die Pruefung wirkt. - MERCHANT-ZAHL OFFENSIV: "We would rather run 23 merchants whose data we can stand behind than pad the number to 25." Dreht die Schwaeche in eine Haltung, gefolgt von der klaren Frage, ob 25 hart ist. - BEWUSST DRIN GELASSEN, obwohl unbequem: die drei unbeantworteten Juli-Mails. Ein Satz, keine Entschuldigung, dafuer eine Zusage (benannter Ansprechpartner, Antwort am selben Tag). Begruendung an Kais: Marlou hat die Mails vor sich. Wer sie ignoriert, ist der Partner der ausweicht; wer sie benennt und eine Zusage danebenstellt, ist der Partner der aufgeraeumt hat. Bei jemandem, der uns schon abgeschaltet hat, ist Glaubwuerdigkeit die Waehrung, nicht Selbstbewusstsein allein. - BEWUSST NICHT: keine Datensatzzahl behauptet (Zeile steht noch auf Processing), keine "alles perfekt"-Formulierung. Jede Zahl ist nachpruefbar bis zum Dateinamen - genau das traegt den Rest. ## Brief gesendet, Tag abgeschlossen (21:03 CEST) - Kais hat die selbstbewusste Fassung ueber "Follow Up On Case" an Fall 05599496 gesendet. - TAGESBILANZ: 3 Fehler gefunden und behoben (alle gemergt), Availability-Feed laeuft wieder und ist belegt, Google-Fall eroeffnet und beantwortet, AWS-Kosten geklaert und Wache eingerichtet, Onboarding-Werkzeug gebaut. - DREI EIGENE FEHLDIAGNOSEN an einem Tag: Datadog als Kostenursache, AppConfig-Version 2 als "Mine", beinahe die leere Feed-Datei. Jedes Mal klang die Erklaerung plausibel, jedes Mal hat erst der Blick auf die FUNKTIONIERENDE Seite sie widerlegt. Kais gegenueber offen benannt, mit dem Schluss: Die Leserechte waren die richtige Entscheidung - Daten haben mich korrigiert, nicht Vorsicht. - Als Memory gesichert: mutiger-auftreten-heisst-umordnen (selbstbewusster wirken durch Reihenfolge und Nachpruefbarkeit, nicht durch staerkere Behauptungen). ## Google antwortet ein zweites Mal am selben Abend (21:05 CEST, Donna) - "Regarding re-enabling your integration, we have escalated this with our team. We will reach out to you once we have an update." - ZWEI DINGE BESSER ALS SIE KLINGEN: (1) Es antwortet DONNA - dieselbe Person, die am 21.07. die Abschaltmail geschrieben hat. Der Fall liegt bei der Entscheiderin, nicht bei der ersten Reihe. (2) "escalated with our team" heisst raus aus dem Support und bei denen, die den Schalter umlegen koennen. - KEINE ZUSAGE, aber das ist normal: Eine Wiedereinschaltung ist keine Support-Entscheidung. - EMPFEHLUNG an Kais: JETZT NICHTS ANTWORTEN. Ein "danke" waere hoeflich und wuerde unsere inhaltliche Nachricht im Verlauf nach unten schieben. Der letzte inhaltliche Beitrag im Fall soll unserer sein. - NACHFASSEN erst am Donnerstag, 10.09., falls still. Nicht frueher - sie haben heute innerhalb weniger Stunden zweimal geantwortet. In der Uebergabe notiert. - ZU KAIS' FRAGE nach mutigerem Auftreten: Zwei Antworten am selben Abend, eine davon von der Entscheiderin persoenlich, nach zwei Monaten Funkstille. Der Ton hat funktioniert.