Der Nutzer konnte in einer Praesentation nicht kontern, und die Ursache war
real: Alles, was BehoerdenKlar von ChatGPT unterscheidet (Erinnerungen,
Kalender, Antwort-Entwurf), steckte in der App — und die ist noch nicht
veroeffentlicht. Das Web-Produkt, das Kunden heute kaufen, war im Kern nur
'Brief erklaeren'.
Kalender (.ics, rein im Browser, nichts wird hochgeladen):
- Frist und Termin mit Erinnerung 3 Tage und 1 Tag vorher
- Zeilen nach BYTES gefaltet (RFC 5545), damit Arabisch/Tigrinya nicht reissen
- Termin 23:30 endet korrekt am naechsten Tag
- Wanduhrzeit ohne Zeitzone = Ortszeit des Geraets
- getestet: Frist, Termin mit Uhrzeit, Mitternacht, langer arabischer Text,
Brief ohne Datum (-> keine Datei)
Anruf-Hilfe (Worker-Schema um kontakt + anruf erweitert):
- Telefonnummer als tel:-Knopf, Aktenzeichen hervorgehoben
- Spickzettel: Satz auf Deutsch + Bedeutung in der Nutzersprache
- Prompt-Regel: Kontaktdaten nur, wenn woertlich im Brief. Getestet mit Brief
ohne Nummer -> telefon: null, nichts erfunden.
Nebenbei zwei bestehende Fehler behoben:
- Optionale Ergebniskarten wurden nie ausgeblendet: Beim zweiten Brief stand
die Checkliste des ERSTEN Briefs noch da. Jetzt Reset zu Beginn.
- dir=auto auf den Ergebnistexten: Arabisch/Farsi/Urdu wurden im Web
linksbuendig dargestellt (in der App war das schon behoben).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Screenshot des Nutzers zeigte: Wer ein Link-Konto hat, landet auf einer
Link-Ansicht mit gespeicherter Karte, schwarzem 'Pay'-Knopf und einem
kleinen, englischen 'Pay without Link' als einzigem Ausweg. Fuer Menschen,
die Deutsch kaum lesen, ist das eine Sackgasse — und das ist genau die
Zielgruppe.
payment_method_types[0]=card schaltet die automatische Methodenwahl ab und
damit auch Link. Jeder sieht jetzt dieselbe Ansicht mit Kartenfeldern.
ACHTUNG fuer spaeter: Solange diese Angabe gesetzt ist, erscheinen KEINE
weiteren Methoden, auch wenn sie im Dashboard freigeschaltet werden. Wer
PayPal oder Klarna anbieten will, muss sie hier ergaenzen.
Kauf nach der Aenderung geprueft: liefert weiter gueltige cs_live_-Seiten.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wer von der tuerkischen Seite kam, landete bisher auf einer deutschen
Stripe-Seite — fuer die Zielgruppe die groesste Huerde im Kaufvorgang.
/kaufen nimmt jetzt 'sprache' entgegen und gibt sie als locale an Stripe
weiter. Nur Sprachen aus STRIPE_SPRACHEN werden geschickt: Ein unbekannter
Wert laesst Stripe die Session mit 400 ablehnen, der Kauf waere kaputt. Fuer
Arabisch, Tigrinya usw. (kennt Stripe nicht) wird nichts mitgeschickt, dann
waehlt Stripe selbst anhand des Browsers.
Alle drei Kauf-Stellen geben die Sprache mit: Sprachseiten fest ihre eigene,
Demo-Seite die dort gewaehlte Zielsprache, Startseite 'de'.
Geprueft: tr/de/pl/ar liefern Bezahlseiten, und eine erfundene Sprache faellt
sauber zurueck statt den Kauf zu brechen.
Stripe Link (die vorausgewaehlte Schnellzahlung) laesst sich NICHT per API
abschalten — laut Stripe-Docs nur in den Zahlungsmethoden-Einstellungen des
Dashboards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Beim Nachgehen der Frage 'warum gibt es auf den Sprachseiten kein Payment'
kam heraus: Die Web-Demo antwortete AUSSCHLIESSLICH auf Deutsch. Die
Uebersetzung war bisher reine App-Funktion — und die App gibt es noch nicht.
Kauf-Knoepfe auf der tuerkischen Seite haetten also 2,99 EUR fuer eine
deutsche Antwort kassiert. Deshalb zuerst der Worker:
- /demo nimmt jetzt 'zielsprache' entgegen (28 erlaubte Codes, Whitelist —
der Wert geht nie als freier Text in den Prompt, sonst koennte man eigene
Anweisungen einschleusen).
- Der deutsche Fachbegriff bleibt deutsch, nur dessen Erklaerung wird
uebersetzt — der Nutzer muss ihn im Brief wiederfinden.
- demo.html hat eine Sprachauswahl und merkt sich die Wahl; die Sprachseiten
verlinken mit ?sprache=xx.
Erst danach die Sprachseiten: Demo-Knopf als Haupt-Handlung (es gab bisher
GAR KEINEN — man konnte das Produkt in 27 Sprachen nicht einmal ausprobieren)
und ein Kauf-Abschnitt mit uebersetzter Pflicht-Einwilligung nach §356 BGB.
Geprueft: 27 Dateien ohne Syntaxfehler, keine offenen Platzhalter, Kauf
liefert cs_live_. Zwei Tippfehler im bulgarischen Text korrigiert.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ohne gesetztes STRIPE_WEBHOOK_SECRET starb der Handler in hmacHex mit einer
Worker-Exception (error 1101 / HTTP 500). Jetzt: sauberes 503 mit Log-Hinweis.
JSON.parse ist zusaetzlich abgefangen -> 400 statt Absturz.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
401/403 vom KI-Dienst sagte bisher 'machen Sie ein besseres Foto'. Jetzt
eigener Zweig (ki_konfig) mit ehrlicher Meldung.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- demo.html: Kauf-Block mit Paketen (5/15 Analysen), Guthaben-Banner,
Pflicht-Einwilligung (sofortige Leistung, Widerruf erlischt), Rückkehr
von Stripe (/kauf-status), Wallet-Token in localStorage, bezahlte
Analysen umgehen die Gratis-Sperre und zählen das Guthaben herunter.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- /kaufen: Stripe-Checkout-Session (REST, kein SDK)
- /kauf-status: nach Rueckkehr Zahlung pruefen -> Guthaben aktivieren ->
signiertes Wallet-Token (HMAC) zurueckgeben
- /stripe-webhook: Signatur pruefen -> Guthaben aktivieren (idempotent) ->
Wiederherstellungs-Link per Brevo mailen
- demoHandler: nimmt optional walletToken; gueltiges Guthaben umgeht die
Gratis-Grenzen, wird nach Erfolg um 1 verringert
- neue Secrets: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET,
TOKEN_SIGNING_SECRET, BREVO_API_KEY; PAKETE-Mapping (Price-ID->Credits,
echte IDs noch einzutragen)
Typecheck gruen. Noch nicht deployed (wartet auf Stripe-Einrichtung).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Website: alle canonical/OG/hreflang/Sitemap/robots-URLs auf behoerdenklar.de
(alle Sprachseiten, Demo, Ratgeber)
- Worker: Demo-CORS erlaubt jetzt behoerdenklar.de (und www), nicht nur
pages.dev -> Demo funktioniert auf der neuen Domain
- eigene Domain via Cloudflare Pages Custom Domain verbunden (SSL aktiv)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fehler: Der anonyme Erst-Versuch war auf 1 pro IP (30 Tage) begrenzt.
Teilen sich mehrere Menschen eine Leitung (Familie, WLAN, Mobilfunk/CGNAT),
bekam der Zweite sofort 'E-Mail noetig' statt einer Analyse. Trat auch
beim Testen ueber denselben Anschluss auf.
- IP- und Anon-Zaehler jetzt TAEGLICH (Datum im Schluessel), 48h TTL
- Anonyme Erst-Analysen pro Anschluss/Tag: 3 (statt 1/30 Tage)
- IP-Gesamtlimit pro Tag: 8 (statt 3/30 Tage)
- 'Wallet'-Schutz unveraendert: globales Tagesbudget 100 + Turnstile +
E-Mail-Hash (dauerhaft 1x/Adresse)
- Client: email_noetig markiert den Browser NICHT mehr als verbraucht
(sonst dauerhafte Blockade ohne gelungene Analyse); localStorage-Key
auf 'bk_demo_v2' umbenannt -> setzt falsche Testphasen-Staende zurueck
Ende-zu-Ende verifiziert: frischer Erst-Upload liefert wieder das Ergebnis.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Backend-Proxy (Cloudflare Worker in proxy/): API-Key serverseitig,
Modell-Whitelist, max_tokens-Deckel, Tageslimits pro Gerät und IP
- Modell-Split: Analyse auf Sonnet 5, Übersetzung/Antwort auf Haiku 4.5
- Bild-Downscaling auf 2000px vor dem Upload (ScanScreen)
- Expo SDK 56 -> 57 Upgrade
- Freemium: 3 Gratis-Analysen mit lokalem Zähler und Paywall-Hinweis
- Einstellungen: API-Key-Feld nur noch im Dev-Modus (NUTZT_PROXY)
- Build-Setup: Bundle-IDs, eas.json, Splash-Screen-Plugin
- Tests: jest-expo + 17 Tests für die Ampel-/Fristlogik
- Rechtliches: Datenschutzerklärung (Entwurf), Webseite (webseite/,
live auf behoerdenklar.pages.dev), Store-Texte (store/)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
JUSNandClaude Opus 5.5