# Daily Log — 2026-09-12 ## GOOGLE GIBT DIE PRODUKTION FREI (13:52 CEST, Kais TG 12145) Marlou (Fall 05599496) schreibt: "you may re-enable your integration via the Actions Center > Configuration > Account & Users." Damit ist die Abschaltung vom 21.07.2026 aufgehoben — sieben Wochen nach dem Stopp, sechs Tage nach unserem Brief mit dem Feed-Nachweis. **Was den Ausschlag gab (Reihenfolge belegt):** 06.09. Availability-Feed erstmals erfolgreich in Produktion (Availability_Feed_production_1788719523.json.gz, 1 Shard, 0 Issues, 0 Errors), danach der Brief mit Durranis Merchant-ID und dem Dateinamen als Nachweis. Donna eskalierte am 06.09. 21:05 intern. Heute die Freigabe. **Einschalten kann nur Kais** (kein Aria-Zugang zum Actions Center). ### Nach dem Einschalten zu messen, nicht anzunehmen - Inventory-Zahl: stand auf 1, muss auf 23 gehen. - Durrani: hing auf "Processing", Status muss kippen. ### WIEDERHOLUNGSRISIKO, offen angesprochen Marlou schreibt "We will keep on monitoring your integration". Die Bedingung aus dem Abschaltbescheid ("no fewer than 25") ist UNVERAENDERT. Wir stehen bei 23. Google schaltet frei, ohne die Schwelle zu senken — die Wiederholung ist damit eingebaut, nicht abgewendet. Es fehlen genau zwei Betriebe. Place-IDs liegen geprueft vor: - Izmir Kebap Haus: ChIJMZU-BQC3oEcRO1BnNJJOkZU - Grill & Doener Haus by Theo: ChIJUQH5VgB9vkcRDQztf55d9A8 Fehlend je: Telefonnummer und Tischplan. Kais gefragt, ob ich die Onboarding-Pruefung (projekte/rwg-prod-uebernahme/onboarding/onboard.py pruefen) vorbereiten soll. ### Unabhaengig weiter offen Durrani laeuft buchungsseitig ueber DISH; Googles Buchungsseite nennt DISH als Partner. Auch nach der Freischaltung schaltet Google dort nicht von allein auf KADiCon um. ## STUNDEN SPAETER: Google entkoppelt einen Merchant (16:49 CEST, Kais TG 12147, Screenshot) Automatische Mail von reserve-partners-support, 16:47: "the below inventory has been unmatched in the last 24 hours by our automated internal systems due to our matching policy. A total of 1 entity was affected. Type: Merchant. Id: 97fb451b-aa94-47ae-b5aa-a38e2aa5270d" **Zuordnung:** 97fb451b = **Falkenburg Dinner** (info+falkenburg@kadicon.de), Belvederer Allee 26A, 99425 Weimar. NICHT Durrani — meine DISH-Vermutung traf nicht zu. ### Unsere Seite ist nachweislich sauber (prod gelesen, read-only) googlePlaceId `ChIJA4QxtjcbpEcRvF6dzcxCMQw` gesetzt, loest ueber die Places-API korrekt auf "Falkenburg Dinner, Belvederer Allee 26A, 99425 Weimar", business_status OPERATIONAL. Adresse, Telefon (+491721764825), timezone gesetzt. features.reservation true, reservation.googleReservations.enabled true. ### Kontrollgruppe gezogen (alle Betriebe, Places-API gegen jede Place-ID) Einziger Unterschied bei Falkenburg: Googles Eintrag hat KEINE Telefonnummer. - OHNE Telefonnummer bei Google: 3 — Falkenburg Dinner, Orient Kebap, Street Kebab - MIT Telefonnummer: 18, alle OPERATIONAL Damit ist die fehlende Telefonnummer der plausibelste Grund, aber NICHT bewiesen: die anderen zwei sind noch verknuepft. Pruefbare Vorhersage: bei zutreffender Hypothese sind Orient Kebap und Street Kebab die naechsten Entkopplungen. ### SCHWERERER FUND: die Betriebszahl stimmt nicht prod-kennungen.txt hat **22** Zeilen (nicht 23). Darin steht ein ZWEITER Durrani-Mandant `22130b68-82e8-4b95-95c6-cc2abfee1079` (info+durrani@kadicon.de): googlePlaceId LEER, googleReservations enabled=False. Eine Doppelanlage, die fuer Google nicht existiert. Der echte Durrani `4e22f973-36d5-4e8c-b8a3-c85a7b87cf10` (Merchant-ID aus support-antwort-2.md, Zugang .secrets/durrani.env) steht NICHT in prod-kennungen.txt; er hat Place-ID `ChIJzwqZMLAlvUcRXke2IYWni14`, Brentanostrasse 9 Gelnhausen, googleReservations enabled=True. **Echte Zahlen:** matchbar vor heute 22 (21 aus der Liste + echter Durrani), nach der Entkopplung 21. Schwelle unveraendert 25. Die Luecke ist VIER Betriebe, nicht zwei. Meine Aussage von heute Morgen ("zwei Anrufe, dann sind wir drueber") war falsch und wurde gegenueber Kais korrigiert. ### An Kais gegeben 1. Actions Center: Falkenburg neu verknuepfen. 2. Telefonnummer bei Google fuer die drei nachtragen lassen (nur ueber den Google-Eintrag des Betriebs moeglich). 3. Durrani-Duplikat klaeren. Nachforschung angeboten, wartet auf Antwort. **Zusammenhang mit dem 02.07.:** damals fielen die Merchants von 35 auf 1. Wenn das dieselbe automatische Entkopplung war, laeuft die Ursache der Juli-Abschaltung weiter und die heutige Freigabe heilt sie nicht. Nicht belegt, aber die Mail zeigt den Mechanismus erstmals im Klartext. ## EINGESCHALTET: Integration status Enabled (18:03 CEST, Kais TG 12151, Screenshot) Actions Center > Account and users > Account: Partner ID 20002024, Account name KADiCon, Integration status "RwG: E2E Integration" mit gruenem Haken **Enabled**. Die Abschaltung vom 21.07.2026 ist damit auch in der Oberflaeche aufgehoben. **An Kais: der Schalter ist nicht das Ergebnis.** Zwei Zahlen im Actions Center zeigen, ob die Freischaltung durchschlaegt: - Merchants / Inventory: stand auf 1. Erwartung nach der korrigierten Zaehlung 21 (nicht 23). - Falkenburg: erscheint es als unmatched, und wird eine Neuverknuepfung angeboten? Der Availability-Feed laeuft regulaer 05:00 UTC; spaetestens danach muss die Zahl stimmen. ## Googles Gegenbestaetigung (18:04 CEST, Kais TG 12153, Screenshot) Automatische Mail von reserve-partners-support@google.com: "SEVERITY_LOW [prod]: KADiCon your integration has been restored on 2026-09-12 16:02:34 GMT" "Your integration with Reserve with Google has been reinstated via the partner portal." Damit ist der Zustandswechsel von GOOGLES Seite bestaetigt, nicht nur in unserer Oberflaeche. Belegter Zeitstempel: 2026-09-12 16:02:34 GMT (= 18:02:34 CEST). **Erkenntnis zum Kanal:** diese automatischen Mails an info@kadicon.de sind die Fruehwarnung. Ueber denselben Weg kam heute die Falkenburg-Entkopplung und mit hoher Wahrscheinlichkeit auch die Abschaltung am 21.07. Wenn dort niemand taeglich liest, bleibt die naechste Abschaltung wieder wochenlang unbemerkt — das erklaert die sieben Wochen Stillstand. ANGEBOTEN (nicht gebaut, wartet auf Kais): Wache auf diesen Posteingang nach dem Muster der AWS-Kostenwache — still im Normalfall, Meldung bei jeder "unmatched"- oder Abschaltmail. Weiter offen: Merchant-/Inventory-Zahl im Actions Center (Erwartung 21). ## KORREKTUR: Googles Merchant-Liste hat 40 Eintraege (18:05 CEST, Kais TG 12155, Screenshot) **Meine Zaehlung war grundfalsch.** Der Screenshot der Merchant-Liste im Actions Center zeigt "1 - 20 of 40", alle mit Matched=Yes und RwG-E2E=Ready. Ich hatte von 21 matchbaren Betrieben gesprochen. Meine Zahl kam aus prod-kennungen.txt (22 Zeilen) — das ist unsere lokale Onboarding-Datei, NICHT Googles Bestand. Die Schwelle 25 ist bei 40 laengst erfuellt; die ganze "Luecke von vier Betrieben" war eine Fehlmessung an der falschen Quelle. Klassischer Fall von [[candidate-set-is-its-own-blind-spot]]: die Kandidatenmenge selbst war die Fehlerquelle, nicht die Zaehlung darin. **Nebenbefund aus derselben Liste:** Izmir Kebap Haus steht mit `993266c7-7a71-44d5-bccf-57420b7060d7` drin — ich hatte es als noch nicht angebunden gefuehrt (Brain-Stand "zurueckgestellt, fehlen Telefonnummer und Tischplan"). Auch das ist ueberholt. ### Kais will das Durrani-Duplikat 3921b1d3 loeschen — GEWARNT, nicht ausgefuehrt `3921b1d3-e01d-42d2-8c38-d5b052867939` steht in Googles Liste als "Restaurant Durrani", Matched Yes, Ready. Das ist die ID, die am 31.08. als Durranis Merchant-ID aus dem JWT gezogen wurde (Daily-Log 2026-08-31, Zeile 626). Die Merchant-ID in support-antwort-2.md an Google lautet dagegen `4e22f973-36d5-4e8c-b8a3-c85a7b87cf10`. **Risiko:** wenn 4e22f973 NICHT in den 40 steht, ist 3921b1d3 der einzige funktionierende Durrani-Eintrag und das Loeschen entfernt ihn statt eines Duplikats. Irreversibel. An Kais: erst pruefen, ob 4e22f973 in der Liste auftaucht. ### Falkenburg "nicht auf der Liste" — noch kein Befund Kais sieht Falkenburg nicht. Die Liste ist nach Merchant-ID sortiert (nicht nach Name) und zeigt nur 1-20 von 40. Seite 2 pruefen, bevor wir es als verschwunden fuehren. ### Drei Ebenen von IDs, die nicht deckungsgleich sind (Merkposten) 1. KADiCon-Tenant-IDs (prod-kennungen.txt, z.B. Falkenburg 97fb451b) 2. Googles Merchant-IDs in der Actions-Center-Liste (z.B. ALIBABA 106e71ae, Durrani 3921b1d3) 3. Die in der Support-Mail genannte Durrani-ID 4e22f973 Die Unmatching-Mail nannte 97fb451b — also eine Tenant-ID, die in Googles Liste so nicht auftaucht. Verhaeltnis der drei Ebenen ist UNGEKLAERT und muss vor jeder Aussage zu Merchant-Zahlen geklaert werden. ## URSACHENSPUR: der Feed liefert keine Telefonnummer (18:08 CEST, Kais TG 12157, Screenshot) Kais hat Falkenburg auf Seite 2 gefunden (meine Sortier-Vermutung stimmte) und den Dialog "Match merchant info" geoeffnet. **Google hat den richtigen Kandidaten VORAUSGEWAEHLT** ("Falkenburg Dinner, Belvederer Allee 26A, 99425 Weimar, Germany"). Ein Klick auf SAVE stellt die Verknuepfung wieder her. So an Kais gegeben. **Der eigentliche Fund steht rechts unter "Here's the information you provided":** - Merchant name: Falkenburg Dinner - Merchant address: Belvederer Allee 26A, 99425 Weimar - Address type: Unstructured - URL: None provided - Merchant ID: `fbe2a03e-f616-40df-a069-6f9612ae5944` - **Phone: Not available** In unseren Produktionseinstellungen hat Falkenburg `+491721764825` (heute selbst gelesen). Im Merchant-Feed an Google kommt die Nummer NICHT an. Damit ist die fehlende Telefonnummer keine Eigenschaft von Googles Places-Eintrag, sondern eine Luecke in unserer Uebertragung — eine Ursache, keine Korrelation. **WICHTIG zur eigenen Messung:** meine Kontrollgruppe von vorhin (18 mit / 3 ohne Telefonnummer) hat die PLACES-API abgefragt, also Googles oeffentlichen Eintrag — NICHT den, was unser Feed liefert. Das sind zwei verschiedene Datenpunkte, die ich nicht vermischen darf. Gegenprobe an Kais gegeben: denselben Dialog bei einem unauffaelligen Betrieb (Bella Turko) oeffnen. Steht dort eine Nummer, liegt es an einzelnen Datensaetzen. Steht dort auch "Not available", wirft der Feed Telefonnummern grundsaetzlich weg. **VIERTE ID-Ebene:** dieser Dialog nennt Merchant ID `fbe2a03e-f616-40df-a069-6f9612ae5944`, die Entkopplungsmail nannte `97fb451b-aa94-47ae-b5aa-a38e2aa5270d` (= unsere Tenant-ID). Zwei verschiedene Kennungen fuer denselben Betrieb. Zu klaeren, sobald die Verknuepfung steht. ## GEGENPROBE WIDERLEGT DIE HYPOTHESE (18:10 CEST, Kais TG 12159, Screenshot) Derselbe Dialog bei **Bella Turko** (durchgehend stabil verknuepft, nie entkoppelt) zeigt identisch: - Address type: Unstructured · URL: None provided · **Phone: Not available** - Merchant ID `f57b441f-38e9-4334-862b-078b9be9bd34` **Damit ist die Telefonnummer-Hypothese widerlegt.** Der Feed liefert bei ALLEN Betrieben keine Telefonnummer — trotzdem wurde nur Falkenburg entkoppelt. Die fehlende Nummer kann die Ursache nicht sein. Die Gegenprobe hat genau das geleistet, wofuer sie da war ([[counter-probe-finds-what-positive-test-misses]], [[compare-broken-against-working-population]]). **Was als echter Befund bleibt (eigenstaendig, kein Notfall):** unser Merchant-Feed uebertraegt weder Telefonnummer noch URL, und die Adresse geht als "Unstructured" raus. Das ist Datenarmut, die jeden Abgleich schwaecht. Gehoert auf die Liste fuer die Feed-Reparatur, nicht in die Ursachensuche von heute. **Ursache der Entkopplung: UNBEKANNT.** Ich habe heute zwei Erklaerungen versucht (DISH-Konflikt, fehlende Telefonnummer) und beide selbst kassiert. Keine dritte ohne Daten — das waere das Muster, vor dem [[dont-discard-a-hypothesis-whose-test-is-running]] und die Ratequote von heute warnen. **Billigster naechster Test ist Warten:** SAVE klicken. Haelt die Verknuepfung, war es ein Ausrutscher in Googles Automatik. Faellt sie erneut, ist es systematisch — und der zweite Vorfall liefert die Datengrundlage, die heute fehlt. Dafuer waere die angebotene Mail-Wache auf info@kadicon.de der passende Melder. ## DURCHBRUCH: ZWEI Merchant-Eintraege pro Betrieb (18:15 CEST, Kais TG 12161, Screenshot) Kais oeffnete einen ZWEITEN Falkenburg-Dialog. Direktvergleich: | | erster Dialog | zweiter Dialog | |---|---|---| | Merchant ID | `fbe2a03e-f616-40df-a069-6f9612ae5944` | `97fb451b-aa94-47ae-b5aa-a38e2aa5270d` | | Phone | Not available | **+491721764825** | | Match-Kandidat | vorausgewaehlt | **keiner** | `97fb451b` ist unsere echte KADiCon-Tenant-ID und die ID aus der Entkopplungsmail. => **Es gibt zwei Merchant-Eintraege fuer denselben Laden.** Derselbe Doppelanlage-Fall wie bei Durrani (`3921b1d3` vs `4e22f973`). **NEUE URSACHEN-HYPOTHESE, diesmal aus Beobachtung statt Vermutung:** Googles Matching-Policy duldet keine zwei Merchants desselben Partners auf demselben Ort. Beansprucht `fbe2a03e` den Place, fliegt `97fb451b` raus. Das erklaert (a) warum nur Falkenburg betroffen war und (b) warum die Telefonnummer nichts damit zu tun hatte. **WARNUNG AN KAIS, bevor er den Maps-Link eintraegt:** wuerde er den Link bei `97fb451b` setzen, zeigen beide Eintraege auf denselben Ort — der Konflikt waere aktiv wieder aufgebaut. **Die Zahl, die alles zusammenbringt:** 40 Merchants bei rund 22 echten Betrieben. Das riecht nach systematischer Verdopplung und waere die Erklaerung fuer den Einbruch von 35 auf 1 am 02.07.2026, den bis heute niemand verstanden hat. Zwei Fragen an Kais offen: (1) wurde bei `fbe2a03e` schon SAVE geklickt? (2) wie viele Namen kommen in der 40er-Liste doppelt vor? Der Kurzlink loest korrekt auf Falkenburg Dinner, Weimar auf (50.966593, 11.3350545) — geprueft, nicht angenommen. ## AUFLOESUNG: ich habe SANDBOX und PRODUKTION vermischt (18:17 CEST, Kais TG 12163) Kais: "Das erste Bild war Sandbox. Das zweite ist auf der Production Umgebung." Der Screenshot zeigt den Umschalter oben links: **Production | Sandbox**. **DREI eigene Aussagen von heute sind damit falsch:** 1. Die Duplikat-These (zwei Merchant-Eintraege je Betrieb) — es waren zwei UMGEBUNGEN. `fbe2a03e` = Sandbox-Falkenburg, `97fb451b` = Produktions-Falkenburg. 2. "40 Merchants, Schwelle 25 laengst erfuellt" — die 40 waren Sandbox. Produktion zeigt die echten gut zwanzig. Meine Entwarnung von 18:05 gilt NICHT. 3. Die Warnung vor Kais' Loeschwunsch: `3921b1d3` war die Sandbox-Durrani-ID. In Produktion steht `4e22f973-36d5-4e8c-b8a3-c85a7b87cf10` sauber mit Matched=Yes — genau die ID aus support-antwort-2.md. Kais' Absicht war richtig, meine Warnung ueberfluessig. **Lehre:** Ich habe Screenshots aus zwei Umgebungen als eine Datenlage gelesen und daraus drei Befunde gebaut. Der Umgebungsschalter war im Bild sichtbar. Vor jeder Aussage aus einem Actions-Center-Screenshot zuerst pruefen, welche Umgebung oben aktiv ist. ### Produktions-Ist-Stand (aus dem Screenshot, IDs = unsere KADiCon-Tenant-IDs) - **Falkenburg Dinner `97fb451b`: "NO ELIGIBLE MATCHES", RwG-E2E "Disabled"** — der einzige mit Disabled. Google findet von allein keinen passenden Ort, deshalb auch kein vorausgewaehlter Kandidat im Dialog (anders als in Sandbox). - **Alle uebrigen: Matched=Yes, RwG-E2E "Processing"** (nicht Ready). Normaler Zustand kurz nach der Freischaltung; nach dem Feed um 05:00 UTC muessten sie auf Ready kippen. - Restaurant Durrani `4e22f973`: Matched=Yes, Processing. ### An Kais gegeben Den Maps-Link JETZT eintragen — bei "NO ELIGIBLE MATCHES" ist das URL-Feld genau der vorgesehene Weg (Link, Add, SAVE). Meine Bremse von 18:15 war ein Fehlalarm. Wenn die Eintraege nach dem naechtlichen Feed nicht auf Ready gehen, bei Marlou nachfassen. ## URL abgelehnt, kanonische Form nachgereicht (18:19 CEST, Kais TG 12165) Google lehnte `https://www.google.de/maps/place/Falkenburg+Dinner` ab: "We are unable to process the provided URL. Please verify the URL meets all of the Google Maps URL requirements listed in the developer documentation." Grund: die Kurzform ohne Orts-Kennung (keine CID, keine Place-ID, keine Koordinaten). Nachgereicht, beide aus der heutigen Places-API-Abfrage (nicht geraten): 1. `https://maps.google.com/?cid=878556849704361660` — die URL, die Googles Places-API selbst als kanonische URL fuer diesen Ort zurueckgibt (Feld `url`). 2. `https://www.google.com/maps/place/?q=place_id:ChIJA4QxtjcbpEcRvF6dzcxCMQw` — Variante ueber die Place-ID. ## URL-Anforderung in der Doku nachgelesen (18:21 CEST) Beide von mir vorgeschlagenen Formen wurden abgelehnt ("Invalid URL - refer to the URL requirements documentation", Add-Knopf bleibt grau). Statt weiter zu raten die Doku gelesen: developers.google.com/actions-center/verticals/reservations/waitlists/partner-portal/inventory/maps-url-matching **Verbindliche Regel:** "It must be the full URL to the Google Maps listing. Short urls and links to Google Search results are not supported." Gueltig ist nur das Muster `https://www.google.com/maps/place/...` (volle Adresszeile aus Google Maps). Doku-Beispiel: `https://www.google.com/maps/place/Googleplex/@37.4219999,-122.0840575,15z/data=!4m2!3m1!1s0x0:0x6c296c66619367e0?sa=X&ved=...` Ausdruecklich NICHT unterstuetzt: goo.gl/maps.app.goo.gl-Kurzlinks, Google-Suchergebnisse. Meine `maps.google.com/?cid=`-Form gehoert ebenfalls nicht zum Muster — eigener Fehler, so an Kais gemeldet. **Geliefert** (Kais' Kurzlink aufgeloest, .de -> .com, Sitzungsparameter entfernt): `https://www.google.com/maps/place/Falkenburg+Dinner/@50.966593,11.3350545,17z/data=!3m1!4b1!4m6!3m5!1s0x47a41b37b6318403:0xc3142cccd9d5ebc!8m2!3d50.9665897!4d11.3376348!16s%2Fg%2F11zh4s9lnr` Erkennungszeichen fuer Gueltigkeit: der Add-Knopf wird klickbar. **Nebenbefund, der den Feed-Punkt haertet:** die E2E-Matching-Guidelines empfehlen fuer bessere Trefferquoten ausdruecklich "Add URL, telephone, and category information". Genau diese drei liefert unser Merchant-Feed nicht (heute im Dialog gesehen: URL None provided, Phone bei Sandbox not available, Address type Unstructured). Damit ist die Feed-Armut keine Randnotiz, sondern ein dokumentierter Verstoss gegen Googles eigene Empfehlung. Weiterer Doku-Hinweis: die Suche IMMER in Google Maps beginnen, nicht in der Google-Suche — letztere liefert eine mit dem Werkzeug unvertraegliche URL. ## URL AKZEPTIERT (18:22 CEST, Kais TG 12170) "Candidates list was successfully updated." Die volle google.com/maps/place-URL wurde angenommen. Der Kandidat "Falkenburg Dinner, Belvederer Allee 26A, 99425 Weimar, Germany" steht jetzt oben im Dialog, ausgewaehlt, SAVE ist aktiv. An Kais: SAVE klicken, danach muss die Listenzeile von "NO ELIGIBLE MATCHES"/"Disabled" auf "Yes"/"Processing" springen. **Was die Sackgasse geloest hat:** nicht raten, sondern die Doku lesen. Drei URL-Formen waren vorher abgelehnt worden (Kurzlink, cid-Form, place_id-Form). Erst die dokumentierte Muster-Vorgabe `https://www.google.com/maps/place/...` mit voller Adresszeile hat funktioniert ([[read-the-spec-before-guessing-scope]] — beim vierten Anlauf angewendet, haette beim ersten gehoert). ## FALKENBURG REPARIERT (18:23 CEST, Kais TG 12172) Produktions-Merchant-Liste: **Falkenburg Dinner `97fb451b`: Matched=Yes, RwG-E2E=Processing.** Von "NO ELIGIBLE MATCHES"/"Disabled" zurueck in die Reihe. Die Entkopplung von 16:47 ist repariert — Ablauf: Maps-URL im vorgeschriebenen Format eintragen, Add, SAVE. **Alle Betriebe stehen auf "Processing", keiner auf "Ready".** Konsistent mit dem Zustand kurz nach der Freischaltung. Der Feed um 05:00 UTC ist der naechste Pruefpunkt. **OFFENE ZAHL, bewusst nicht behauptet:** die Fusszeile sagt "Items per page: 100" und "1 - 100 of 100". Im Bild sind 23 Zeilen sichtbar, deren Kennungen von `0df250a3` bis `fd1e29b3` laufen, also ueber den gesamten Hex-Bereich — das spricht fuer eine vollstaendige Liste von 23, nicht fuer 100. Kais gebeten, bis ans Listenende zu scrollen. Nach drei falschen Zahlen an einem Tag (21 / 40 / "Schwelle erfuellt") keine vierte ohne Beleg. ## BELEGT: Inventory von 1 auf 23 (18:24 CEST, Kais TG 12174) Actions Center, Produktion: **"Total received inventory: 23 merchants"**. Vor der Freischaltung stand die Zahl auf 1. Damit ist belegt, dass die Freigabe nicht nur den Schalter umlegt, sondern das Inventar wirklich wieder ankommt. Die Fusszeilen-Angabe "1 - 100 of 100" war die Seitengroesse, nicht die Menge — meine Skepsis war berechtigt, die Zahl aus der Inventory-Anzeige ist die verbindliche. **Damit gilt die Rechnung von heute Morgen wieder:** Schwelle 25, Stand 23, es fehlen ZWEI Betriebe. Meine zwischenzeitliche Entwarnung ("40, Schwelle laengst erfuellt") war der Sandbox-Fehler und ist endgueltig vom Tisch. Fehlend: Izmir Kebap Haus (`ChIJMZU-BQC3oEcRO1BnNJJOkZU`) und Grill & Doener Haus by Theo (`ChIJUQH5VgB9vkcRDQztf55d9A8`). Place-IDs geprueft, es fehlen Telefonnummer und Tischplan. Google schreibt "we will keep on monitoring" — die Abschaltbedingung ist unveraendert. ## TAGESBILANZ 12.09.2026 **Erreicht:** Produktion nach sieben Wochen wieder freigeschaltet (Googles eigene Bestaetigung, 16:02:34 GMT), Inventory von 1 auf 23, Falkenburg-Entkopplung erkannt und repariert. **Offen:** ob die Eintraege nach dem Feed um 05:00 UTC von Processing auf Ready gehen. **Angeboten, wartet auf Kais:** Onboarding-Pruefung fuer die zwei fehlenden Betriebe; Mail-Wache auf info@kadicon.de als Fruehwarnung fuer kuenftige Entkopplungen. **Eigene Fehlerquote heute, zum Mitzaehlen:** drei falsche Zahlen (21 / 40 / "Schwelle erfuellt"), zwei widerlegte Ursachenthesen (DISH, Telefonnummer), eine falsche Warnung (Durrani-Loeschung), eine ueberfluessige Bremse (Maps-Link), drei abgelehnte URL-Formen vor dem Doku-Blick. Gemeinsame Wurzel bei fast allen: aus einer unklaren Quelle geschlossen, statt die Quelle zuerst zu klaeren. ## ONBOARDING-PRUEFUNG FUER DIE ZWEI FEHLENDEN VORBEREITET (18:26 CEST, Kais-Auftrag TG 12176) Dateien: `projekte/rwg-prod-uebernahme/onboarding/neue-betriebe/{izmir,theo}.json` Beide `onboard.py pruefen` -> **"Alles in Ordnung. Naechster Schritt: mail"** (nebenwirkungsfrei, schreibt nichts, verschickt nichts). Aus der Places-API geholt statt erfragt: - **Izmir Kebap Haus** (`ChIJMZU-BQC3oEcRO1BnNJJOkZU`): `+4915562060037`, taeglich 10:00-21:00, OPERATIONAL, 22 Bewertungen. **Adresse hat KEINE Strasse**: nur "08340 Schwarzenberg/Erzgebirge". - **Grill & Doener Haus by Theo** (`ChIJUQH5VgB9vkcRDQztf55d9A8`): `+4917646184473`, Brenderweg 112, 56070 Koblenz, Mi-Sa 12:00-21:00, So 13:00-22:00, Mo+Di geschlossen, OPERATIONAL, 23 Bewertungen. **OFFEN, nur bei den Wirten zu holen:** 1. Tischplan — die Werte in beiden Dateien (`4x2, 2x4`) sind MEINE PLATZHALTER, damit die Pruefung laufen konnte. Damit darf nichts live gehen. Deutlich an Kais gesagt. 2. Bei Izmir die Strassenadresse (Googles Eintrag hat keine; die E2E-Guidelines empfehlen ausdruecklich "complete street-level addresses"). 3. Telefonnummern und Zeiten bestaetigen lassen — Google-Daten koennen veralten. ## GOOGLE RAEUMT SELBST EIN INVENTAR-PROBLEM EIN (aus dem Screenshot-Banner) "A fix is being rolled out to resolve recent merchant inventory staleness. Please reach out in the cases tab if you notice any persistent latency in changes to your merchant inventory." Das ist die bislang plausibelste Erklaerung fuer die Falkenburg-Entkopplung — und sie stammt von Google, nicht von mir. Nach zwei eigenen widerlegten Thesen (DISH, Telefonnummer) ist das die erste Ursachenangabe mit einer Quelle. **Handlungsweg daraus:** gehen die Eintraege nach dem Feed um 05:00 UTC nicht auf Ready, ueber den Faelle-Reiter melden — genau das schlaegt der Banner vor. ## KAIS SETZT FUENF TESTBUCHUNGEN IN PRODUKTION AB (18:36 CEST, TG 12178-12182) Kais: "Ich habe paar Reservierungen abgesetzt (ich wollte es testen und werde es anschliessend stornieren)". Fuenf Bestaetigungsmails als Screenshots: | Betrieb | Termin | Personen | Ort | |---|---|---|---| | Bella Turko | So 13.09. 19:00 | 2 | Coburg | | Bozan Grill | Fr 18.09. 19:30 | 4 | Gotha | | Falkenburg Dinner | Mo 21.09. 20:00 | 8 | Weimar (ID 9559-E95F-2303-513E) | | Doener/Pizza/ AFG Spezial | Mi 23.09. 20:30 | 2 | Muenchen (ID 6160-AA48-C948-1C4F) | | Apetito Grill Apolda | Do 24.09. 21:30 | 6 | Apolda | **SOFORT GEWARNT (harte Regel aus dem Brain):** jede Buchung loest neben der Gastmail eine zweite an `settings.restaurant.email` aus. Bei diesen Betrieben ist das `info+@kadicon.de`, und diese Aliasse leiten an die echten Laeden weiter (von Kais selbst bestaetigt). Die Wirte bekommen also echte Reservierungsmails; bei 8 Personen in Weimar und 6 in Apolda blockiert das halbe Gastraeume. Dringendste: Bella Turko morgen 19:00. An Kais: sofort stornieren (die Stornierung schickt eine zweite Mail hinterher und klaert es fuer den Wirt), mit Bella Turko anfangen. **POSITIVER BELEG, der alles andere schlaegt:** Die Buchung bei **Falkenburg** ging durch — zehn Minuten nach der Neuverknuepfung. Damit ist die gesamte Kette von Googles Buchungsseite ueber den Booking-Server bis in unsere Datenbank nachweislich funktionsfaehig. Das ist der staerkste Beleg fuer die Freischaltung, den dieser Tag hergeben konnte — besser als jede Statusanzeige. **ANGEBOTEN:** Testbetrieb mit einer nicht weiterleitenden Adresse anlegen (`kais@kadicon.de` leitet laut Notiz nicht weiter), damit kuenftige Tests niemanden mehr betreffen. **ZUGESAGT:** nach den Stornierungen in der Datenbank pruefen, ob alle fuenf wirklich storniert angekommen sind — nicht auf die Bestaetigungsmails verlassen. ## SCHWERER PRODUKTIONSBEFUND: 130 Phantom-Reservierungen (18:44 CEST) Beim Nachprufen von Kais' Testbuchungen (Prime Kebab zeigte "5 Reservierungen · 10 Personen" fuer Mo 14.09.) gefunden. Abfrage ueber `GET /api/reservation?date=` (Endpunkt heisst SINGULAR, /api/reservations gibt 404), alle 22 Betriebe x 5 Tage (13.-17.09.): | | Anzahl | |---|---| | Reservierungen mit `customerData.name = "System generated"` | **130** | | echte Google-Buchungen (alle von Kais heute) | 6 | **Merkmale der Phantom-Eintraege:** `source: admin`, `state: approved`, `comment: "Seeded at 2026-09-07T04:00:00.718Z"` (bzw. 11.09., 12.09.), belegen echte `tableIds`. **Die Zeitstempel sind immer 04:00:00 UTC** — ein taeglicher Cron/Job schreibt gegen die PRODUKTIONSdatenbank. Verteilung (Top): Falkenburg 12 · Ruhi Doener 11 · Prime Kebab 11 · Azad Grill 10 · Bozan Grill 9 · AFG Spezial 8 · Bella Turko 7 · Antep 7 · Urfa Grill 7. Betroffen sind 20 der 22 Betriebe. **Warum das jetzt kritisch ist:** Wir haben Google heute um Freischaltung gebeten und stehen unter Beobachtung ("we will keep on monitoring"). Belegen Phantom-Eintraege die Tische, sieht ein echter Gast keine Verfuegbarkeit oder bekommt eine Absage — genau das Signal, das zur naechsten Abschaltung fuehrt. **Erster Hinweis, dass es bereits wirkt:** Kais' Prime-Kebab-Buchung (`98fa13e4-8420-4f85-a691-19752291bcf0`, source google, 14.09. 13:00-13:30 UTC, 3 Personen) steht auf **`state: "rejected"`** — nicht approved. Ursache NICHT belegt; die zeitliche Ueberschneidung mit den Seeds ist zu pruefen, nicht anzunehmen. An Kais gemeldet mit der Frage, ob ich der Quelle des Seeding-Jobs nachgehen soll. Parallel meldet Kais: Bozan Grill auf den 16.09. geaendert, Falkenburg und AFG Spezial stehen gelassen. ## QUELLE DER PHANTOM-RESERVIERUNGEN: ein "Fake reservations seeder" (18:50 CEST) Datei: `apps/backend/src/app/features/reservation/cron/reservation-seeder.cron.ts` (lokaler Klon `/home/aria/codex-workspace/kadicon`), Klasse `ReservationSeederCron`. Der Doc-Kommentar im Code lautet woertlich: `/** Fake reservations seeder for restaurants that have Google reservations enabled */` **Konstruktion (alles im Code belegt, nicht gefolgert):** - Laeuft AUSSCHLIESSLICH in Produktion: `if (Stage !== StageId.PRODUCTION) { ...return }` - Zielgruppe per SQL: Settings mit `googleReservations ->> 'enabled' = 'true'` - `const EXCLUDED_RESTAURANTS = ['4e22f973-36d5-4e8c-b8a3-c85a7b87cf10']` — genau Durrani, unser Referenzbetrieb gegenueber Google - 4 bis 10 Reservierungen je Betrieb je Lauf, verteilt ueber 28 Tage, `state: approved`, `customerData: { name: 'System generated' }`, `comment: 'Seeded at '` - Zeitplan `'0 0 3 * * *'`, ueberschreibbar per AppConfig-Schluessel `reservation_seeder_cron_schedule` (die Ist-Zeitstempel zeigen 04:00 UTC, also dort geaendert) **Historie (alle Commits von Awais Saeed):** | Datum | Commit | Titel | Wirkung | |---|---|---|---| | 16.03.2026 | `2a76b257` | "create cron job to insert fake reservations for google integration enabled restaurants" | angelegt, kein Umgebungsfilter | | 29.04.2026 | `6c61c5f5` | "skip reservation seeding on non staging environments" | Schutz: nur `StageId.STAGING` | | 01.05.2026 | `a9aee863` | "log testing slots for production environment" | dreht `STAGING` -> `PRODUCTION` UND nimmt Durrani aus | **Der Titel des letzten Commits beschreibt seine Wirkung nicht.** Er klingt nach Logging und kehrt den Umgebungsschutz um. Genau die Klasse Befund, die ein Review findet und ein Titel-Ueberflug nicht. **Risikoeinschaetzung, so an Kais gegeben:** Google hat heute freigeschaltet und schreibt "we will keep on monitoring". Zu wenige Betriebe sind ein Formfehler. Vorgetaeuschte Auslastung ist eine andere Kategorie — und Kais hat am 29.08. aus genau diesem Grund das Fake-Listing abgelehnt ([[reserve-google-merchant-consent-gate]]). **Zwei Fragen an Kais offen:** (1) kennt er den Job und was war der Zweck? (2) abschalten? Der Zeitplan haengt an AppConfig, also ohne Deploy aenderbar — derselbe Weg wie am 06.09. beim Availability-Feed. Aria hat dort nur Leserechte. ## BEWERTUNG DES SEEDERS: was tun, lassen, aendern (18:58 CEST, Kais-Auftrag TG 12197) ### Entwarnung zuerst: die abgelehnten Buchungen sind Kais' eigene Stornierungen Alle google-Buchungen 12.-25.09. abgefragt: **11 gesamt, 8 approved, 3 rejected**. Die drei rejected sind Bella Turko (13.09.), Apetito Grill Apolda (24.09.) und Prime Kebab (14.09.) — genau die, die Kais nicht behalten wollte (er meldete: Bozan auf 16.09. geaendert, Falkenburg und AFG Spezial gelassen). Mein Verdacht "erste Google-Buchung seit Monaten und abgelehnt" war FALSCH. Nebenbefund mit Wert: der Stornierungsweg funktioniert nachweislich. ### Groessenordnung gemessen (Stichprobe 6 Betriebe x 29 Tage) Bella Turko 3 Tische / 33 Seeds · Maxx 3/32 · Nec 3/29 · Azad 4/41 · Burna 5/25 · Amo's Steak Doener 6 Tische / **0** Seeds (Ausreisser, Ursache ungeklaert). Summe 160 Seeds bei 24 Tischen -> Hochrechnung **rund 587 Fake-Reservierungen** im 28-Tage-Fenster. Kapazitaetsbelegung grob 3 % — wirtschaftlich klein. ### Der eigentliche Risikopunkt (aus Googles Policy, nachgelesen) "Your integration can be disabled when there are many CreateBooking errors" und "high error rate for CreateBooking availability errors indicate that your BatchAvailabilityLookup slot click response doesn't accurately reflect real-time inventory" (developers.google.com/actions-center/verticals/reservations/e2e/policies/platform-policies). Heute unkritisch, weil der Seeder um 04:00 UTC laeuft und der Feed um 05:00 UTC — der Feed sieht die Seeds. **Diese Reihenfolge ist nirgends festgeschrieben**, beide Zeitplaene haengen getrennt in AppConfig. Kippt sie, meldet der Feed Slots als frei, die real belegt sind, und der Seeder produziert exakt die Fehlerrate, die zur automatischen Abschaltung fuehrt. ### Empfehlung an Kais | | Was | Begruendung | |---|---|---| | **Abschalten** | den Seeder | Zeitbombe an der Cron-Reihenfolge; und keine gute Antwort gegenueber Google auf "warum entstehen taeglich System-generated-Reservierungen" | | **Aendern** | die am 01.05. umgedrehte Zeile zurueck auf `StageId.STAGING` | Werkzeug bleibt zum Testen erhalten, trifft die Produktion nicht mehr | | **Stehen lassen** | die bestehenden ~587 Eintraege | schon im Feed; ein Sprung nach oben faellt mehr auf als das Auslaufen binnen 28 Tagen. Erst Zufluss stoppen | | **Sofortweg** | AppConfig `reservation_seeder_cron_schedule` auf einen nie feuernden Wert | ohne Deploy, derselbe Weg wie am 06.09. beim Availability-Feed | Angeboten: den AppConfig-Eingriff vorbereiten. Aria hat dort nur Leserechte, Kais legt um.