diff --git a/marketing/praesentation-mbe/plan-bis-29-10.md b/marketing/praesentation-mbe/plan-bis-29-10.md
new file mode 100644
index 0000000..064e293
--- /dev/null
+++ b/marketing/praesentation-mbe/plan-bis-29-10.md
@@ -0,0 +1,350 @@
+# BehördenKlar: Plan bis zum MBE-Termin am 29.10.2026
+
+Alle 63 Funde aus den 6 Perspektiven hat ein Prüfer bestätigt, aber er hat viele davon heruntergestuft. Unten zählt die Schwere nach dieser Prüfung. Doppelte Funde sind zusammengefasst, die IDs stehen in Klammern.
+
+---
+
+## 1. Urteil
+
+**Frage 1: Läuft die Vorführung flüssig genug?**
+- **Für die Vorführung: Fast.** Der geplante Weg ist kurz. Am PC wählt man die Sprache und klickt einmal, am Handy sind es etwa 6 bis 7 Fingertipps. Der PC zeigt dabei live an, was am Handy passiert. Vier Dinge können den wichtigsten Moment aber kippen:
+  - Die zweisprachige Analyse (PC Deutsch, Handy Arabisch) ist **noch nie mit echter KI gelaufen und nicht deployed** (LI1, TE3).
+  - Scheitert die Übersetzung, stehen zwei Knöpfe „Deutsch | Deutsch“ da und die Person bekommt Deutsch statt Arabisch (BE2, TE2).
+  - Vor 12 Uhr zeigt die Ampel beim Musterbrief Gelb statt Rot (LI2).
+  - Ein zweiter Brief vom Handy kommt am PC nicht mehr an (TE4).
+- **Für den Alltag im Testmonat: Noch nicht.** Es gibt mehrere stille Sackgassen:
+  - Steht am PC „Deutsch“, bekommt die Beraterin kein Deutsch (TE1).
+  - Wer schon 2 Gratis-Analysen gemacht hat, sieht das Code-Feld nicht mehr (AN1).
+  - Wird die Seite neu geladen, ist die Verbindung still weg (BE1, TE5).
+  - Fehler am Handy kommen am PC nicht an (RA8).
+- Die meisten Punkte sind in Minuten bis wenigen Stunden behoben. Nach der MUSS-Liste lautet die Antwort für die Vorführung: **Ja**.
+
+**Frage 2: Ist es bequem genug für die Beratungsstelle?**
+- **Für einen kostenlosen Test: Fast.** Das reicht, wenn die MUSS-Liste erledigt ist und Justin die Grenzen offen sagt.
+- **Was schon gut ist:**
+  - Wenige Klicks am PC.
+  - Die ratsuchende Person setzt das Häkchen selbst am eigenen Handy.
+  - Mit Code erscheint kein Kaufangebot.
+  - Fehlgeschlagene Analysen kosten nichts.
+  - Oben steht der eigene Name der Stelle („Kostenlos über MBE Donnersberg“).
+- **Was für den Dauerbetrieb noch fehlt:**
+  - Nur ein Foto pro Brief, mehrseitige Briefe gehen am Handy nicht (BE4).
+  - Kein Ausdruck (BE8).
+  - Kein Knopf „Fertig – nächste Person“ (BE9, DA8).
+  - Die Briefzahl ist veraltet und das Ablaufdatum unsichtbar (BE3).
+  - Die Bedienung am Handy ist nur Deutsch (RA1).
+  - Es gibt keine Kurzanleitung für Kolleginnen (BE5).
+- **Die größte Hürde ist aber nicht die Technik, sondern das Papier.** Ungeklärt ist, wer verantwortlich ist, wenn die Beraterin am Dienst-PC hochlädt, und ob dafür ein Vertrag zur Auftragsverarbeitung (AVV) nötig ist (DA1). Das Datenschutz-Blatt ist veraltet und ging im Juli wahrscheinlich schon an die MBE (AN6, DA6).
+
+---
+
+## 2. MUSS vor dem 29.10.
+
+Zusammen etwa 12 bis 14 Stunden.
+
+### Wochenplan
+
+| Tag | Was |
+|---|---|
+| **Do 22. / Fr 23.** | Code-Paket M1 und Sätze in der Datenschutzerklärung (M5c), wenn Zeit ist auch schnelle SOLLTE-Punkte |
+| **Sa 24.** | Deploy (erst Worker, dann Webseite), Vorführ-Code anlegen, Generalprobe 1 |
+| **So 25.** | Fehler aus der Probe beheben, Datenschutz-Blatt und Kurzanleitung schreiben |
+| **Mo 26.** | MBE anrufen (wer ist Träger?), Generalprobe 2. **Spätester Deploy-Termin.** |
+| **Di 27.** | MBE-Code anlegen, Handzettel neu erzeugen, QR testen, alles drucken. Ab abends nichts mehr am Code ändern. |
+| **Mi 28.** | Generalprobe 3 genau wie am Termin, Geräte vorbereiten, Checkliste |
+
+### M1. Code-Korrekturen vor dem Deploy (zusammen ca. 3–4 Std.)
+
+| # | Aufgabe | Funde | Aufwand |
+|---|---|---|---|
+| a | Die Ampel in **Kalendertagen** rechnen, so wie die App (`ampel.ts`). Zusätzlich den Termin im Musterbrief auf **Di 03.11.2026, 10:30** legen. Im Spickzettel „Termin in 7 Tagen“ durch „Termin nächste Woche“ ersetzen. Die Ampelzeile soll „Termin am …“ oder „Frist bis …“ sagen. Die Frist-Aufgabe nur anhängen, wenn wirklich die Frist das früheste Datum ist. | LI2, LI6 | 30–45 Min. |
+| b | „Deutsch \| Deutsch“ verhindern: `analyse_de` nur anhängen, wenn `sprache ≠ 'de'`. Scheitert die Übersetzung, am Handy den Hinweis „Übersetzung hat nicht geklappt, hier auf Deutsch“ zeigen. `[observability] enabled = true` in `wrangler.toml` eintragen. | BE2, TE2, LI8 | 30–45 Min. |
+| c | Die Beraterin bekommt immer Deutsch: Das Häkchen „auch Deutsch“ am PC immer zeigen, standardmäßig an. `d=1` setzen, egal welche Sprache am PC eingestellt ist. | TE1 | 15 Min. |
+| d | Das Code-Feld (`details#codeTeil`) aus `#eingabe` herausnehmen. Danach mit `bk_demo_v2=2` testen. | AN1 | 15–30 Min. |
+| e | Nach dem ersten Ergebnis den Handy-Modus beenden. Am Handy steht dann: „Für den nächsten Brief am Computer noch einmal auf ‚Lieber mit dem Handy fotografieren‘ tippen.“ | TE4, BE4 | 20 Min. |
+| f | Einwilligung: Das Häkchen nach **jeder** Analyse zurücksetzen (`konsens.checked = false`). Im Einrichtungs-Modus einen eigenen Text zeigen: Er nennt Gesundheit, Herkunft und Aufenthalt sowie Anthropic (USA) und sagt „in der Regel nach 30 Tagen gelöscht, kein Training“. | DA2, LI11 | 45 Min. |
+
+### M2. Deploy und Generalprobe
+
+**Funde:** LI1 (Blocker), TE3, BE2, LI8, DA7
+**Aufwand:** 3–4 Std. für die Proben, dazu Zeit für Korrekturen
+
+- **Bis Sa 24.10., spätestens Mo 26.10.**
+  1. Zuerst den Worker deployen (`cd proxy && npx wrangler deploy`).
+  2. Danach die Webseite (Ordner `webseite/`).
+  3. Wenn die Webseite vor dem Worker live geht, laufen „Code einlösen“ und die Übergabe ins Leere.
+- **2–3 komplette Durchläufe genau nach Ablaufplan:**
+  - gleicher Laptop, gleiches Handy, Hotspot, gedruckter Musterbrief
+  - Arabisch **und** Farsi
+  - einmal über mobile Daten
+  - mit Stoppuhr
+  - Bildschirmfotos für den Notfall machen
+- **Dabei prüfen:**
+  - Falscher Code ergibt „Diesen Code kennen wir nicht“.
+  - Der Laptop zeigt „Handy verbunden“.
+  - Am Ende stehen zwei Knöpfe **„Deutsch | العربية“**.
+  - Die Ampel ist rot.
+  - Auf der Live-Datenschutzseite steht „9b.“.
+- **Wenn „Deutsch | Deutsch“ erscheint:** sofort mit `npx wrangler tail` ins Log schauen.
+- **Unsicher:** Ob die Rate-Limit-Einstellung `[[ratelimits]]` im kostenlosen Cloudflare-Tarif läuft, ist nicht geprüft. Scheitert der Deploy daran: den Block und `index.ts:832-836` vorerst entfernen (TE3).
+
+### M3. Codes richtig anlegen
+
+**Funde:** LI3, AN2, BE3, TE11
+**Aufwand:** Minuten
+
+```
+node tools/einrichtungs-code.js neu "MBE Donnersberg (Vorführung)" VORF --briefe 30 --bis 2026-11-30
+node tools/einrichtungs-code.js neu "MBE Donnersberg" MBE --briefe 100 --bis 2026-12-18
+node tools/einrichtungs-code.js stand <CODE>
+```
+
+- **Ein festes Datum nach dem 26.11.** lässt der MBE Zeit für die Bestellung. Sonst sperrt der Code mitten im Bestellvorgang und löscht den Zugang bei den Ratsuchenden.
+- Handzettel und Spickzettel sagen dann „Test bis 18.12., Auswertung am 26.11.“ statt „1 Monat“.
+- Nach dem Anlegen mit `stand` prüfen, dass kein „NaN“ und das richtige Datum erscheint.
+- Den Vorführ-Code vor den Proben am Laptop einlösen.
+
+### M4. Handzettel überarbeiten und neu erzeugen
+
+**Funde:** AN9, LI5, BE6, DA4, AN2
+**Aufwand:** ca. 1 Std.
+
+- Den MBE-Code in `handzettel.html:190` eintragen. Der QR muss auf `/demo?code=MBE-…` zeigen.
+- „Ihr Zugangscode für den Beratungs-PC“ statt „Code für Ihre Ratsuchenden“ schreiben.
+- Dazu den Satz: „Einmal am Beratungs-PC öffnen, dann ist auch ‚Mit dem Handy fotografieren‘ kostenlos.“
+- „gültig bis 18.12.2026“ eintragen.
+- Datenschutz-Sätze korrigieren: „in der Regel nach 30 Tagen (länger nur bei Verdacht auf Missbrauch), kein Training“. Und: „Den Brief selbst muss die KI lesen. Ende-zu-Ende verschlüsselt ist zusätzlich die Übergabe zwischen PC und Handy.“
+- **Den gedruckten QR mit dem Handy testen.** Erst wenn „Kostenlos über MBE Donnersberg“ erscheint, 5 Stück drucken. Die alte `handzettel.png/pdf` ohne Code nicht mehr verwenden.
+
+### M5. Datenschutz-Unterlagen, nur das Nötigste
+
+**Funde:** DA1, DA4, DA5, DA6, AN6
+**Aufwand:** ca. 3 Std.
+
+- **a) Mo 26.10. bei der MBE anrufen:** Wer ist der Träger (z. B. Diakonie oder Caritas)? Gibt es eine eigene AVV-Vorlage? (DA1)
+- **b) Neues Datenschutz-Blatt für die Webseite schreiben (1–2 Seiten):**
+  - Datenfluss: Foto, dann Worker, dann Anthropic. Die QR-Übergabe ist verschlüsselt und nach 15 Minuten weg.
+  - Unterauftragsverarbeiter: Cloudflare und Anthropic.
+  - Rollenaussage: „Lädt die Stelle selbst hoch, arbeiten wir als Auftragsverarbeiter. Einen AVV mit Verschwiegenheitsklausel bekommen Sie auf Wunsch.“
+  - **Das alte Blatt vom Juli nicht mehr weitergeben.** Darin steht für die Webseite Falsches.
+- **c) In der Datenschutzerklärung (geht mit dem Deploy raus):**
+  - Für Anthropic nur „EU-Standardvertragsklauseln“ schreiben, nicht das EU-US-Datenschutzabkommen (DPF), denn dafür gibt es keinen Beleg (DA5).
+  - Den 30-Tage-Satz wie in M4 anpassen (DA4).
+
+### M6. Spickzettel (`ablaufplan.html`) nachschärfen
+
+**Aufwand:** 30–45 Min.
+
+- **Checkliste am Vorabend:**
+  - Vorführ-Code eingelöst, oben steht „Kostenlos über …“ (LI3).
+  - Gedruckten QR getestet (AN9).
+- **Kurz vor dem Termin** (LI4):
+  - iPhone: Automatische Sperre auf „Nie“, Stromsparmodus aus.
+  - Mac: im Terminal `caffeinate -d`.
+- **Bei der Vorführung:**
+  - QR erst live erzeugen. Steht „abgelaufen“ da, einfach neu klicken (LI10).
+  - Die Handy-Schritte üben: scrollen, Häkchen, Brief auswählen, Foto, verwenden (LI7).
+  - „Ein bis zwei Minuten“ sagen und den Datenschutz-Teil fest in die Wartezeit legen (LI8).
+  - Den Kalender-Knopf nur am Handy zeigen (LI9).
+  - Den Mitnehmen-QR von einer Beraterin mit ihrem eigenen Handy scannen lassen (LI10).
+  - Den Fachbegriff zeigen, der tatsächlich erscheint (LI10).
+  - Zeile 75 ehrlich machen: „Das Ergebnis bleibt, solange die Seite offen ist. Der Kalender-Eintrag bleibt immer.“ (RA6)
+- **Angebotsteil:**
+  - Den Code gleich live am PC einer Beraterin einlösen und das Lesezeichen mit `?code=` setzen (LI5, BE3).
+  - Eine Beraterin macht einmal den Handy-Ablauf an **ihrem** Dienst-PC (BE10).
+  - „Auch auf dem Handy nutzen“ erst zeigen, wenn am Laptop der MBE-Code eingelöst ist. Sonst gibt der Laptop den Vorführ-Zugang weiter (AN8).
+- **Ehrliche Antworten auf typische Fragen:**
+  - Mehrseitige Briefe: „Zurzeit ein Foto pro Erklärung, die Seite mit Betreff und Frist. Scanner-PDF am PC geht mehrseitig, dann aber nur in einer Sprache.“ (BE4)
+  - Bedienung auf Deutsch: „Die Erklärung kommt in der Muttersprache, die Bedienung übersetze ich als Nächstes.“ (RA1, LI7)
+  - AVV und Verantwortung: „Bekommt Ihr Datenschutzbeauftragter von mir.“ (DA1)
+  - Ausdrucken: „Kommt als Nächstes.“ (BE8)
+- **Notfallplan:**
+  - Der Laptop hängt, das Handy zeigt das Ergebnis: einfach das Handy zeigen (LI4).
+  - „Deutsch | Deutsch“: „Hier hat die Übersetzung gehakt“ sagen und die Bildschirmfotos zeigen (LI8).
+
+---
+
+## 3. SOLLTE vor dem 29.10.
+
+In dieser Reihenfolge, so weit die Zeit reicht. Zusammen ca. 7–9 Std.
+
+| # | Aufgabe | Funde | Aufwand |
+|---|---|---|---|
+| S1 | **Fehler bei Arabisch (rechts nach links), sichtbar in der Vorführung:** Die Briefart-Plakette nicht in Courier setzen, sondern `font-family:inherit`, `letter-spacing:0`. Ampel- und Fristzeile mit KI-Text in `<bdi>` packen. Den Absatz bei den Fachbegriffen mit `dir=auto` versehen. `.todo::before` mit `margin-inline-end`. Danach am Vorführ-Handy ansehen. | RA2 | < 1 Std. |
+| S2 | **Arabische Minimal-Bedienung:** Einwilligung, Startknopf, Verbunden-Banner, Wartetext und „Verbindung fehlgeschlagen“ auf Arabisch, dazu `dir=rtl`. Im Termin eine arabischsprachige Beraterin gegenlesen lassen. | RA1, DA3, BE7, LI7 | 2–3 Std. |
+| S3 | **Handy-Seite aufräumen:** zum Banner scrollen (`scrollIntoView`). Im Einrichtungs-Modus die Gratis-Texte ersetzen. Im Kamera-Modus (a=k) Kaufbereich und Code-Feld immer ausblenden. Den Knopf nicht grau machen, sondern beim Tippen auf das fehlende Häkchen hinweisen. Sprachliste mit deutschem Zusatz („العربية – Arabisch“, „پښتو – Paschtu“). | RA7, BE11 | ca. 1 Std. |
+| S4 | **Robustheit:** Warnung „Seite wirklich verlassen?“, solange der PC wartet. Wartezeit bei jeder Handy-Meldung verlängern. `meldeAnPc` auch im catch-Zweig aufrufen. `dateiFeld.value = ''` setzen. Nach 5 fehlgeschlagenen Abfragen oder mehr als 3 Minuten „analysiert“ einen Hinweis am PC zeigen. Im Worker den Anthropic-Aufruf in try/catch setzen. localStorage nur über einen abgesicherten Helfer ansprechen. | BE1, RA8, TE10, BE10, TE7 | 1–2 Std. |
+| S5 | **Anruf-Sätze beim Mitnehmen übersetzen:** `mitBedeutung` aus der angezeigten Version nehmen und `l=` in den Mitnehmen-QR schreiben. | RA3, TE9 | 15 Min. |
+| S6 | **Code-Eingabe tolerant machen:** alles außer A–Z und 0–9 entfernen, den Bindestrich vor den letzten 4 Zeichen wieder einsetzen, die Sperrgrenze auf 30 Fehlversuche anheben. | AN7, TE6, RA5 | 20 Min. |
+| S7 | **Nutzung zählen ab Tag 1:** pro Analyse über einen Einrichtungs-Code ein eigener Eintrag mit Datum. Wird auch die Sprache gezählt, einen Satz in Abschnitt 9a der Datenschutzerklärung ergänzen. | TE8, AN4 | 30 Min. |
+| S8 | **Kontingent leer oder abgelaufen:** Den Code nicht löschen, kein Kaufangebot zeigen, der PC hört auf zu warten und zeigt einen Kasten mit Justins Telefonnummer. Oben „gültig bis …“ anzeigen. | BE3, AN2 | 1–2 Std. |
+| S9 | **Handy-Sprache übernehmen:** aus `navigator.languages` vorauswählen, aber nicht speichern. | RA4 | 15 Min. |
+| S10 | **QR-Code am PC größer:** auf ca. 280–300 px (eine Zeile CSS). | BE12 | 1 Min. |
+
+---
+
+## 4. Zum Termin mitbringen
+
+- **Geräte:** Laptop mit eingelöstem Vorführ-Code, eigenes Handy (Sperre aus, Akku voll), Hotspot, Ladegeräte.
+- **Musterbrief** (Termin 03.11.) 2× gedruckt (LI2).
+- **Handzettel mit MBE-Code**, 5× (M4).
+- **Kurzanleitung „So geht's am Beratungs-PC“**, 5× (BE5): eine Seite mit 5 Schritten:
+  1. Lesezeichen genau auf `behoerdenklar.de/demo?code=MBE-…` setzen.
+  2. Sprache wählen.
+  3. „Lieber mit dem Handy fotografieren“ klicken.
+  4. Beim Warten nicht neu laden. Falls doch, steht das Ergebnis am Handy, dort auf Deutsch umschalten.
+  5. Nach jeder Person die Seite neu laden und die Sprache prüfen (BE9, DA8). Kalender-Einträge nur am Handy machen.
+
+  Dazu die Telefonnummer. Die Bildschirmfotos erst nach dem Deploy machen.
+- **Neues Datenschutz-Blatt**, 2× „für Ihre Datenschutzbeauftragte“, mit Rollenaussage (M5, DA1, AN6). Dazu sagen: „Das Blatt aus dem Juli beschrieb die App.“
+- *Optional:* eine einseitige Papier-Einwilligung zum Abheften für Klientinnen (DA2, DA3).
+- **Bildschirmfotos der Generalprobe** als Notfall-Ersatz (LI1).
+- **3 Fragen für die Auswertung** (genutzt? welche Sprache? Zeit gespart?) und einen festen Termin am 26.11. (AN4).
+- **Nicht mitbringen:** das alte Factsheet/PDF vom Juli und den alten Handzettel ohne Code.
+
+**Entscheidung vor dem Termin, wohin der Code geht (BE6, AN3):** Empfehlung für den Test: Der Code bleibt bei den Beraterinnen. Ratsuchende nutzen ihn nur in der Beratung über „Mit dem Handy fotografieren“. Dieser Weg gibt den Zugang nur für die Sitzung weiter. Einzelnen Personen kann die Beraterin den Zugang gezielt über „Auch auf dem Handy nutzen“ geben. Achtung: Dieser Zugang bleibt dauerhaft auf deren Handy. Einen Aushang mit Code erst nach der Auswertung machen, wenn die MBE das will.
+
+---
+
+## 5. NACH dem Termin
+
+**Bevor der erste echte Brief am Dienst-PC hochgeladen wird:**
+- AVV-Entwurf (nach dem Muster von GDD oder Bitkom, mit Verschwiegenheitsklausel), technische und organisatorische Maßnahmen (TOMs) in Stichpunkten, ein Absatz für das Verarbeitungsverzeichnis des Trägers (DA1, DA6).
+- Brevo in den AVV-Nachweis aufnehmen (DA6).
+- Die DPA-Verträge von Anthropic und Cloudflare als PDF ablegen und in beiden Konten die Organisation auf „Webklar GbR“ stellen (DA5).
+
+**In Woche 1–2 des Tests:**
+- Mehrere Fotos pro Brief, zählt als 1 Brief (BE4, ca. 1 Tag).
+- Knopf „Drucken / als PDF speichern“ mit Druck-Ansicht und Teilen-Knopf (BE8, RA6).
+- Knopf „Fertig – nächste Person“ (BE9, DA8).
+- Verbindung nach Neuladen wiederherstellen (sessionStorage) für PC und Handy (BE1, TE5, RA9).
+
+**Im Testmonat:**
+- Die Bedienung in die Hauptsprachen übersetzen und von den Beraterinnen gegenlesen lassen (RA1, BE7, DA3).
+- Aushang und Karten nur, wenn die MBE sie will (AN3).
+
+**Laufender Betrieb:**
+- Zweimal pro Woche `stand` prüfen und montags eine kurze Stand-Mail an die MBE schicken (BE3, AN4).
+- Erinnerung 7 Tage vor Ablauf.
+- Bei einer Zusage sofort `verlaengern`, erst danach die Rechnung schicken (AN2).
+
+**Bis zum 26.11.:**
+- Ein einseitiges Angebot und eine Rechnung (§ 19 UStG), am besten als Jahreskontingent.
+- Die veraltete Zeile 334 in `outreach-september.md` korrigieren (AN5).
+
+**Später:**
+- Guthaben atomar in einem Durable Object führen (TE8).
+- Das Token nicht mehr in den QR-Code legen (BE12).
+- Eigene Adresse für den Worker, z. B. `api.behoerdenklar.de` (BE10).
+- Tagesobergrenze pro Code (BE6).
+- Tests für `/code` und `/uebergabe` in `npm run pruefung` (LI1, TE3).
+- Eingabeprüfung im Werkzeug (TE11).
+- Kleinigkeiten in der Datenschutzerklärung: 48 Stunden statt 30 Tage, E-Mail-Prüfsumme, Kontakt nicht über Gmail (DA9).
+- Webseite und App mit derselben Ampel-Formel (LI2).
+
+---
+
+## 6. Größte Live-Risiken und Gegenmittel
+
+| Risiko | Funde | Gegenmittel |
+|---|---|---|
+| Die zweisprachige Analyse läuft live zum ersten Mal und scheitert oder zeigt „Deutsch \| Deutsch“ | LI1, BE2, TE2 | Bis Sa/Mo deployen, 3 Generalproben, Korrektur M1b, Bildschirmfotos bereithalten, ruhig erklären |
+| Die Analyse dauert deutlich länger als 1 Minute (nicht gemessen) | LI8 | Stoppuhr in der Probe, „ein bis zwei Minuten“ sagen, Datenschutz-Teil in die Wartezeit legen |
+| Das Handy sperrt oder der Laptop schläft ein, das Ergebnis kommt nicht am Laptop an (**unsicher**, ob Safari dabei abbricht) | LI4 | Automatische Sperre „Nie“, `caffeinate -d`, im Notfall das Handy zeigen |
+| Die Ampel zeigt Gelb statt Rot | LI2 | Formel reparieren und Termin im Musterbrief auf den 03.11. legen |
+| Am Laptop ist kein Code eingelöst, das Handy landet in der Gratis-Demo oder ist gesperrt | LI3, LI5 | Vorführ-Code eingelöst, oben muss „Kostenlos über …“ stehen (Checkliste) |
+| Eine Beraterin fotografiert spontan einen zweiten Brief oder Seite 2 | TE4, BE4 | Korrektur M1e und die vorbereitete ehrliche Antwort |
+| „Versteht mein Klient, was er ankreuzt?“ oder „Brauchen wir einen AVV?“ | RA1, DA1–DA3 | S2 (Arabisch), Datenschutz-Blatt mit Rollenaussage, AVV zusagen |
+| Das Netz der Einrichtung sperrt `workers.dev` (**unsicher**) | BE10 | Vorführen über den eigenen Hotspot, am Ende ein Test am Dienst-PC, bei Problemen die IT fragen |
+| Der PC wird beim Warten neu geladen | BE1 | Warnung „Seite verlassen?“ (S4). Das Ergebnis steht trotzdem am Handy, dort auf Deutsch umschalten |
+| Der QR-Code ist abgelaufen | LI10 | Erst live erzeugen, sonst neu klicken |
+
+**Wichtigste Regel:** Was am Mi 28.10. nicht in der Generalprobe lief, kommt nicht mehr in den Code.
+---
+
+## Anhang: alle Funde im Detail
+
+### Beraterin am PC
+_Für die Vorführung am 29.10. ist der Ablauf kurz und überzeugend. Am PC wählt man die Sprache und klickt einmal, am Handy sind es etwa sechs Fingertipps. Danach steht die Erklärung am PC auf Deutsch und am Handy in der Muttersprache. Das gilt aber nur, wenn die zweisprachige Analyse live funktioniert, und die wurde noch nie getestet. Für den Alltag im Testmonat ist es aus Sicht einer Beraterin noch nicht bequem und robust genug. Lädt jemand die Seite neu oder schließt das Handy den Tab, geht still ein Brief verloren. Die Beraterin sieht weder den echten Reststand noch das Ablaufdatum. Es gibt keinen Ausdruck und keine mehrseitigen Briefe, die Handy-Seite ist nur auf Deutsch, und für Kolleginnen ohne Justin fehlt eine Anleitung. Die meisten Punkte lassen sich mit wenigen Stunden Arbeit beheben._
+
+- **BE1 · Neu laden oder Handy-Tab weg: Ergebnis verloren, Brief trotzdem verbraucht** (mittel, stunden, vor Termin) — Am PC: Wer die Seite neu lädt (F5, aus Versehen, oder der Browser stellt sich nach einem Absturz wieder her), während das Handy fotografiert, verliert den Schlüssel der Übergabe. Das Handy schickt sein Ergebnis trotzdem ab, aber niemand holt es mehr ab. Es gibt keine Warnung 'Seite wirklich verlassen?'. Am Handy: Die Verbindung zum PC liegt nur im Arbeitsspeicher. Lädt der Handy-Browser die Seite neu, ist sie weg. Das kann passieren, wenn Android den Tab beim Öffnen der Kamera-App aus dem Speicher wirft; das ist ein Risiko und nicht getestet. Danach ist die Seite eine normale Gratis-Demo ohne Code und ohne Verbindung, eventuell mit E-Mail-Abfrage und Kaufangebot. Der PC zeigt dann 15 Minuten lang '✅ Handy verbunden'. Außerdem läuft die 15-Minuten-Uhr am PC ab Anzeige des QR-Codes und nicht ab der letzten Handy-Meldung: Fotografiert das Handy spät, gibt der PC auf, während das Handy noch analysiert. Jede Wiederholung kostet einen weiteren Brief aus den 100. *Beleg:* webseite/demo.html:1292 (pcWarten nur im Speicher), :806-809 (Handy legt Ergebnis ab, egal ob der PC noch wartet), :609 + :1507-1511 (Handy-Verbindung nur im Speicher, # wird sofort gelöscht), :1316 + :1337-1341 (Ablauf ab QR-Erzeugung), keine beforeunload-Warnung (grep: keine Treffer); proxy/src/index.ts:767/786 (Päckchen verfallen nach 15 Min.) *Vorschlag:* Vor dem Termin nur die billigen Teile (Minuten): 1) beforeunload-Warnung, solange pcWarten aktiv ist. 2) Bei jeder Status-Meldung vom Handy pcWarten.bis verlängern. 3) In die Kurzanleitung schreiben: 'Beim Warten nicht neu laden. Falls doch: Das Ergebnis steht am Handy, dort auf Deutsch umschalten.' sessionStorage-Wiederherstellung für PC und Handy erst nach dem Termin (Stunden).
+- **BE2 · Der Kern der Vorführung (PC Deutsch, Handy Arabisch) ist ungetestet; bei einem Fehler zweimal 'Deutsch'** (hoch, stunden, vor Termin) — Genau der Moment, der die Beraterinnen überzeugen soll, wurde noch nie durchgespielt. Scheitert die Übersetzung mit Haiku, schickt der Worker zwei deutsche Fassungen. Dann zeigen PC und Handy zwei Knöpfe 'Deutsch | Deutsch', und die ratsuchende Person bekommt kommentarlos Deutsch statt Arabisch. Außerdem laufen Analyse (Sonnet) und Übersetzung (Haiku) nacheinander, die Seite verspricht aber 'bis zu einer Minute'. Wie lange es wirklich dauert, ist unbekannt. *Beleg:* proxy/src/index.ts:477-484 (Fallback: analyse und analyse_de beide deutsch, sprache 'de'); webseite/demo.html:857-861 (hängt analyse_de immer als zweite Version an, daher doppelter Knopf); index.ts:395 und :481 (nacheinander); demo.html:383 ('bis zu einer Minute'); laut Hintergrund lokal nicht getestet (kein KI-Schlüssel) *Vorschlag:* Wie vorgeschlagen. Ergänzung: Beim Probedurchlauf nach dem Deploy mindestens zwei Sprachen testen (Arabisch und Farsi) und das Handy einmal über mobile Daten verbinden. Bei 'Deutsch | Deutsch' sofort mit 'npx wrangler tail' ins Worker-Log schauen ('Übersetzung fehlgeschlagen'). Die Code-Korrektur (analyse_de nur bei sprache != 'de' anhängen, plus Hinweis am Handy) dauert Minuten und sollte vor dem Termin rein.
+- **BE3 · Kontingent: Zahl veraltet, Ablaufdatum unsichtbar, leeres Kontingent fällt erst mitten in der Beratung auf** (mittel, stunden, vor Termin) — Als Beraterin sehe ich 'Kostenlos über MBE Donnersberg: 87 Analysen'. Diese Zahl stammt aus meinem eigenen Browser und wird nur durch meine eigenen Analysen kleiner. Nutzen Ratsuchende den Code zu Hause, merkt mein PC das nicht, die Zahl ist zu hoch. Ein Ablaufdatum sehe ich nirgends, obwohl der Server es mitschickt. Ist das Kontingent mitten in der Beratung leer, steht am Handy 'Bitte fragen Sie dort nach', obwohl die Person ja bei uns sitzt. Am PC steht '…aufgebraucht… Bitte dort noch einmal versuchen', und der PC wartet weiter, was sinnlos ist. Passiert es beim direkten Hochladen am PC, wird der Code aus meinem Browser gelöscht und das Kaufangebot für Privatleute erscheint. Nach dem Aufladen muss ich den Code neu eingeben. Eine Vorwarnung wie 'nur noch 5 Briefe' gibt es nicht, und Justin erfährt es auch nicht automatisch. Dazu kommt: Das Werkzeug setzt das Ablaufdatum auf 'heute + 1 Monat'. Wird der Code vor dem 26.10. angelegt, läuft er vor dem Auswertungstermin am 26.11. ab. *Beleg:* proxy/src/index.ts:742 (liefert 'ablauf') vs. webseite/demo.html:1257-1266 (ignoriert ihn); demo.html:596/645 (Zahl aus localStorage), :820 und :1368 (nur eigene Analysen aktualisieren); index.ts:446 (Server zieht für jedes Gerät ab); index.ts:329 + demo.html:766-768 + :1356 (widersprüchliche Meldungen); demo.html:783-790 (Code wird gelöscht) + :655 (Kauf-Block); tools/einrichtungs-code.js:46-50 + :81 (Ablauf = heute + 1 Monat) *Vorschlag:* In dieser Reihenfolge: 1) Code mit festem Datum anlegen: --bis 2026-11-30 (Sekunden). 2) Lesezeichen am Beratungs-PC genau auf behoerdenklar.de/demo?code=MBE-… setzen. Jedes Öffnen ruft dann /code auf (demo.html:1467) und holt den Stand frisch, das löst das 'veraltet' ohne Programmierung. 3) Bei kontingent_leer/abgelaufen den Code NICHT löschen, kein Kaufangebot zeigen, den PC das Warten beenden lassen und einen Kasten mit Justins Telefonnummer zeigen (Stunden). 4) Das Ablaufdatum im Banner anzeigen. 5) Zweimal pro Woche 'stand' prüfen.
+- **BE4 · Mehrseitige Briefe gehen nicht, und Seite 2 landet nicht am PC** (hoch, tag, vor Termin) — Viele Bescheide (Jobcenter, Ausländerbehörde) haben mehrere Seiten. Am Handy kann man nur ein Foto pro Erklärung hochladen. Nach dem ersten Ergebnis hört der PC auf zu warten, das Handy bietet das Hochladen aber wieder an, und das Banner verspricht weiter 'erscheint hier und auf dem Bildschirm'. Ein Foto von Seite 2 erscheint also nur am Handy, kostet einen weiteren Brief und weiß nichts von Seite 1. Bei der Vorführung fällt das nicht auf, weil der Musterbrief einseitig ist. Die Frage kommt aber mit Sicherheit. *Beleg:* webseite/demo.html:331 (input ohne 'multiple'), :679 (nur files[0]), :1348-1352 (PC beendet das Warten nach dem ersten Ergebnis), :814 (Handy öffnet das Hochladen wieder), :1417 (Banner-Text bleibt); musterbrief-auslaenderbehoerde.html hat nur eine .seite *Vorschlag:* Bis 29.10.: Antwort in den Ablaufplan aufnehmen, aber ehrlich formuliert: 'Zurzeit ein Foto pro Erklärung: die Seite mit Betreff und Frist. Mehrseitig geht als Scanner-PDF direkt am PC, dann aber nur in EINER Sprache. Für die Beraterin Deutsch wählen.' Dazu den Handy-Banner nach dem ersten Ergebnis ändern (Minuten). Danach (etwa 1 Tag): 'Weitere Seite hinzufügen', bis zu 4 Fotos in einer KI-Anfrage, zählt als 1 Brief.
+- **BE5 · Keine Kurzanleitung für den Beratungs-PC; der Code ist nach dem Termin schwer wiederzufinden** (mittel, stunden, vor Termin) — Der Handzettel wirbt, erklärt aber nicht, wie man es am PC benutzt. Der PC-Ablauf steht dort nur als ein Satz unter 'Was BehördenKlar kann'. Kolleginnen, die nicht beim Termin waren, wissen nicht, was sie klicken sollen. Das Code-Feld am PC steckt in einem zugeklappten Bereich ganz unten. Öffnet man den Link mit ?code=, verschwindet der Code sofort aus der Adresse. Ein Lesezeichen, das man danach anlegt, enthält ihn also nicht. Löscht der Dienst-Browser beim Schließen die Daten, ist der Code weg und muss gesucht werden. *Beleg:* marketing/praesentation-mbe/handzettel.html:93-176 (nur Werbung und Angebot), :125-128 (PC-Ablauf als Merkmal-Satz); webseite/demo.html:372-377 (Code-Feld in zugeklapptem details), :1467 (reinigeUrl entfernt ?code=) *Vorschlag:* Eine kurze Seite 'So geht's am Beratungs-PC' (5 Schritte, wie vorgeschlagen) ist gut und in Stunden machbar. Das Lesezeichen mit ?code= hat einen Zusatznutzen: Es holt bei jedem Öffnen den aktuellen Briefstand (siehe BE3). Bildschirmfotos erst nach dem Deploy machen, weil live noch der alte Stand läuft.
+- **BE6 · Weitergabe des Codes an Ratsuchende ist ungeklärt und unbegrenzt** (mittel, stunden, vor Termin) — Auf dem Handzettel steht 'Code für Ihre Ratsuchenden' mit einem QR-Code zu demo?code=…. Diesen Link kann man weiterleiten, und jeder, der ihn öffnet, hat den Code dauerhaft gespeichert. Für Einrichtungs-Guthaben greift im Worker kein Tages- oder IP-Limit. Ein Link in einer WhatsApp-Gruppe kann also die 100 Briefe aufbrauchen, und die Beraterinnen merken es erst, wenn es leer ist (siehe BE3). Für Ratsuchende gibt es kein eigenes Material, weder Aushang noch Kärtchen, und nichts in ihrer Sprache. Der vorhandene Weg 'Zugang per QR vom PC aufs Handy' ist ein kleiner Link-Knopf mit der Käufer-Beschriftung 'Auch auf dem Handy nutzen'. *Beleg:* handzettel.html:173-175 + :191 (Code und Link für Ratsuchende); webseite/demo.html:1257-1259 + :1467 (Code wird dauerhaft gespeichert); proxy/src/index.ts:333-342 (Limits nur, wenn nicht bezahlt); demo.html:294 + :1392-1399 (a=g-Knopf) *Vorschlag:* Vor dem 29.10. entscheiden. Empfehlung für den Test: Der Code bleibt bei den Beraterinnen (Handzettel: 'Ihr Zugangscode für den Beratungs-PC' statt 'Code für Ihre Ratsuchenden'). Ratsuchende nutzen ihn nur während der Beratung über 'Lieber mit dem Handy fotografieren' (a=k, nur für die Sitzung). Den a=g-Knopf im Einrichtungs-Modus besser ausblenden oder deutlich als 'dauerhaft' kennzeichnen. Eine Tagesobergrenze im Worker ist eine sinnvolle Notbremse, aber nicht zwingend vor dem Termin, denn die 100 sind selbst schon die Obergrenze.
+- **BE7 · Die Handy-Seite der Ratsuchenden ist komplett auf Deutsch, auch die Einwilligung** (mittel, tag) — Die gewählte Sprache ändert nur die KI-Erklärung. Was die ratsuchende Person am Handy bedienen muss, ist alles Deutsch: der Einwilligungstext mit dem Hinweis auf Anthropic (USA), der Start-Knopf, das Banner 'Mit dem Computer verbunden…', Kamera-Hinweise und Fehlermeldungen. In der Beratung muss ich die Einwilligung also erst übersetzen oder die Person setzt ein Häkchen, das sie nicht lesen kann. Menschlich und beim Datenschutz ist das wackelig. Übersetzte Texte gibt es für die Sprachseiten schon, aber nicht für die Demo. *Beleg:* webseite/demo.html:306-316 (Einwilligung), :332 (Knopf), :1417 (Banner), :728/:832 (Fehlermeldungen); :747 (Sprache geht nur an die KI); tools/sprachseiten/texte.js enthält z. B. kaufKonsens in allen Sprachen, aber keinen Upload-Konsens *Vorschlag:* Wenn das Handy per QR mit Sprache l≠de geöffnet wird, die etwa 8 Texte, die man bedienen muss, in der Zielsprache zeigen: Banner, Einwilligung, Start-Knopf, Kamera-Hinweis, Wartetext und 3 häufige Fehlermeldungen. Mit den häufigsten MBE-Sprachen anfangen (Arabisch, Farsi, Türkisch, Ukrainisch, Russisch, Kurdisch) und von Muttersprachlern gegenlesen lassen. Für den 29.10. reicht eine ehrliche Antwort: 'Die Bedienung am Handy wird als Nächstes übersetzt.'
+- **BE8 · Kein Ausdruck, und am Handy ist das Ergebnis weg, sobald der Tab zu ist** (mittel, stunden, vor Termin) — Viele Ratsuchende wollen Papier, und für die Akte wäre ein Ausdruck praktisch. Es gibt aber weder einen Druck-Knopf noch Druck-Einstellungen. Mit Strg+P druckt man die ganze Seite mit Formular, Einwilligungstext und Fußzeile. Die Erklärungen der Fachbegriffe fehlen auf Papier, weil sie zugeklappt sind. Am Handy wird das Ergebnis nirgends gespeichert. Schließt die Person den Tab oder lädt neu, ist alles weg. Nur der Kalender-Eintrag bleibt. Der Handzettel verspricht aber 'Ergebnis zum Mitnehmen'. *Beleg:* webseite/demo.html: grep 'print' ohne Treffer; :905-917 (Fachbegriffe in zugeklappten details); :565-630 (localStorage speichert nur Sprache/Guthaben, kein Ergebnis); :1508-1511 (# wird gelöscht, Neuladen stellt nichts wieder her); handzettel.html:129-131 *Vorschlag:* Druck-Knopf mit @media print wie vorgeschlagen (Stunden). Er ist aber nicht zwingend vor dem Termin. Wenn die Zeit knapp ist, auf die Frage 'Kann man das ausdrucken?' ehrlich antworten und es danach bauen. Der Druck-Knopf am Handy ('Als PDF speichern') löst nebenbei das Aufbewahren.
+- **BE9 · Nächste Person: Das Ergebnis der vorigen Person bleibt auf dem Bildschirm** (mittel, stunden) — Es gibt keinen Knopf 'Fertig'. Kommt die nächste Person an den Tisch, steht die Erklärung des vorigen Briefs weiter unten auf dem Bildschirm, mit Aktenzeichen und Telefonnummer, bis ein neues Ergebnis sie ersetzt. Auch die Sprache der vorigen Person bleibt eingestellt. Wer das übersieht, schickt der nächsten Person die falsche Sprache aufs Handy. *Beleg:* webseite/demo.html:879-927 (zeigeAnalyse ersetzt erst bei neuem Ergebnis, keine Zurücksetzen-Funktion); :1501 (Sprache wird dauerhaft gespeichert) *Vorschlag:* Wie vorgeschlagen. Bis der Knopf da ist, in die Kurzanleitung schreiben: 'Nach jeder Person die Seite neu laden und die Sprache prüfen.'
+- **BE10 · Dienst-PC mit strengem Netz: Fehler bleiben stumm** (mittel, stunden, vor Termin) — Alle Anfragen gehen an behoerdenklar-proxy.behoerdenbrief.workers.dev, dazu an challenges.cloudflare.com. Ob der Web-Filter der Einrichtung workers.dev-Adressen durchlässt, ist unbekannt; manche Filter sperren diese Adressen. Scheitert das Abfragen am PC, wird der Fehler verschluckt. Die Beraterin sieht 15 Minuten '⏳ Warte auf das Handy …' und dann 'QR-Code ist abgelaufen', ohne Hinweis auf das Netzwerk. Außerdem greift die Seite an mehreren Stellen ohne Absicherung auf den Browser-Speicher zu. Sperrt die IT Website-Daten, bricht das Skript beim Start ab und kein Knopf funktioniert. Das ist eine Bedingung, die nicht getestet ist; die Sprach-Einstellung ist dagegen abgesichert. *Beleg:* webseite/demo.html:540-542 + webseite/uebergabe.js:15-16 (workers.dev); demo.html:534 (Turnstile); demo.html:1359-1361 (Abfragefehler werden still ignoriert), :618 (Handy-Meldungen an den PC ebenso); demo.html:594-597, :601-604, :629-630 (localStorage ohne try/catch) vs. :565-566 (mit try/catch) *Vorschlag:* Punkt 1 ist der wichtigste und kostet nur Minuten. Am Ende des Termins eine Beraterin bitten, den Link an IHREM Dienst-PC zu öffnen und einmal den Handy-Ablauf mitzumachen. Die Punkte 2 und 4 (Meldung nach mehreren Fehlversuchen, try/catch) dauern Minuten bis eine Stunde. Punkt 3 (eigene Adresse für den Worker) kommt später.
+- **BE11 · Oberfläche im Einrichtungs-Modus: Gratis-Texte, falscher Hauptknopf, Sprachliste nur in fremder Schrift** (mittel, minuten, vor Termin) — Auch mit aktivem Code steht oben weiter '2 Analysen gratis', 'Antrag auf Klartext · 2 Gratis-Analysen' und 'Gratis-Demo'. Justin sagt aber '100 Briefe', das verwirrt. Der Knopf, den die Beraterin wirklich braucht ('Lieber mit dem Handy fotografieren'), ist der weiße Zweitknopf unter einem großen, ausgegrauten Hauptknopf. Der ist grau, weil das Häkchen nur für das direkte Hochladen gesetzt ist. Die Sprachliste zeigt nur die Eigennamen in Originalschrift und ist nicht alphabetisch sortiert. 'ትግርኛ' (Tigrinya) oder 'پښتو' (Paschtu) erkennt eine deutsche Beraterin nicht. *Beleg:* webseite/demo.html:268, :277, :284 (feste Gratis-Texte); :332-333 + :667 (Hauptknopf erst nach dem Häkchen aktiv, Handy-Knopf zweitrangig); :556-562 + :1494-1498 (nur Originalnamen) *Vorschlag:* Wie vorgeschlagen, aber die Reihenfolge nach Größe der Sprachgruppe beibehalten (nicht alphabetisch). Wichtiger als das Sortieren ist der deutsche Zusatz ('العربية – Arabisch', 'فارسی – Farsi/Dari', 'پښتو – Paschtu'). Aufwand: Minuten.
+- **BE12 · QR-Code am Bildschirm wird mit Code doppelt so dicht** (niedrig, minuten, vor Termin) — Hat der PC einen Einrichtungs-Code, steckt das komplette Guthaben-Token im QR-Code. Der Code wird dadurch deutlich dichter: 61×61 statt 45×45 Punkte, bei fester Größe von 220 Pixeln nur 3,4 Pixel pro Punkt. Der weiße Rand ist nur 2 Punkte breit. Moderne Handys schaffen das. Ältere, günstige Handys von Ratsuchenden, ein spiegelnder Laptop-Bildschirm oder verkleinerte Browser-Ansicht machen das Scannen aber zäher. *Beleg:* Selbst nachgerechnet mit webseite/qrcode.js: a=k mit Code = 217 Zeichen, QR-Version 11 (61 Module), 3,38 px/Modul; ohne Code = 113 Zeichen, Version 7, 4,49 px/Modul. webseite/demo.html:218 (220 px), :1301 (Token im QR), webseite/uebergabe.js:113 (margin 2) *Vorschlag:* Nur .qr-box .qr auf etwa 280 bis 300 px vergrößern (eine Zeile CSS). Den margin zu ändern ist unnötig. Das Token aus dem QR herauszunehmen kann warten.
+
+### Ratsuchende mit wenig Deutsch
+_Wenn die Beraterin daneben sitzt (QR am PC scannen, a=k), funktioniert der Ablauf: Nach etwa 6 Fingertipps ist der Brief fotografiert, das Ergebnis steht auf Arabisch am Handy und auf Deutsch am PC. Allein zu Hause, mit dem Code vom Handzettel, bleibt ein Ratsuchender mit wenig Deutsch aber an mehreren Stellen hängen. Bis auf den Ergebnistext ist alles auf Deutsch: Einwilligung, Knöpfe, Hinweise, Fehler und Kartenüberschriften. Die Erklärungssprache steht auf Deutsch, obwohl das Handy auf Arabisch eingestellt ist, und nach dem Schließen der Seite ist das Ergebnis weg. Dazu kommen kleine Fehler bei Arabisch (rechts-nach-links) und eine fehlende Übersetzung in der Anruf-Hilfe. Beides sieht man genau in der geplanten Arabisch-Vorführung, und beides lässt sich in Minuten beheben._
+
+- **RA1 · Handy-Seite ist bis auf das Ergebnis komplett Deutsch, auch die Pflicht-Einwilligung** (hoch, tag, vor Termin) — Nach dem QR-Scan sieht der Ratsuchende nur deutschen Text: den Kopf 'Probieren Sie es aus … 2 Analysen gratis', das Verbunden-Banner, die lange Einwilligung (Häkchen ist Pflicht, sonst bleibt der Knopf grau), den Knopf 'Brief auswählen & erklären lassen', 'Ihr Brief wird analysiert…', die Hinweise zu Kamera und Galerie und alle Kartenüberschriften im Ergebnis ('Einfach erklärt', 'Das müssen Sie tun', 'Anrufen', 'Danach werden Sie gefragt', 'Noch 7 Tage Zeit', 'In meinen Kalender eintragen', Rechtshinweis). Wer kaum Deutsch liest, hakt blind an oder bleibt stecken. Bei der Einwilligung nach Art. 9 DSGVO ist das außerdem heikel: Wer den Text nicht lesen kann, willigt nicht wirklich informiert ein. Das ist ein Hinweis, keine Rechtsauskunft. *Beleg:* demo.html:2 (lang="de", kein dir), 306-316 (Einwilligung), 332, 382-383, 446-473, 849, 1083-1084, 1122-1131, 1417. Gerendert bei 390 px Breite mit Handy-Sprache Arabisch: Alles außer den KI-Texten ist deutsch (Screenshots ak.png und am2.png im Scratchpad). Übersetzungen für die Demo-Seite gibt es nicht; tools/sprachseiten/texte.js deckt nur die Startseiten ab. *Vorschlag:* Vor dem 29.10. nur Arabisch, und nur das Nötigste: Einwilligung, Startknopf, Verbunden-Banner, Wartetext, 'Verbindung fehlgeschlagen'. Dazu dir='rtl' am Container, wenn die Sprache ar/fa/ur/ps ist. Den Rest wie die Sprachseiten nachziehen. Im Termin auf jeden Fall offen sagen: 'Die Bedienung ist noch deutsch, die Erklärung kommt in der Muttersprache.' Rechne damit, dass jemand nach der Einwilligung fragt: Die Beraterin kann sie im Moment vorlesen oder übersetzen.
+- **RA2 · Arabisch (rechts-nach-links) an mehreren Stellen falsch dargestellt, sichtbar in der Vorführung** (mittel, stunden, vor Termin) — Vier Stellen sind betroffen. (1) Die Briefart-Plakette über der Kernaussage nutzt Courier mit letter-spacing. Dadurch werden arabische Buchstaben auseinandergerissen ('ر س ا ل ة' statt 'رسالة') und sind schwer lesbar. (2) In der Ampel-Zeile und der Frist-Zeile hängt der arabische Text hinter deutschem 'Noch 7 Tage Zeit · ' bzw. '⚠️ Frist: …'. Die Zeile läuft deshalb links-nach-rechts, und der Schlusspunkt sowie die Klammern landen auf der falschen Seite. (3) Die arabische Erklärung der Fachbegriffe ist linksbündig, der Punkt steht vorne. (4) Bei den Checkbox-Kästchen fehlt der Abstand zum Text. Eine arabischsprachige Beraterin sieht das sofort. *Beleg:* Headless-Chrome-Screenshot bei 390 px mit arabischem Beispielergebnis über eine echte lokale a=m-Übergabe (crop1.png, crop2.png). Code: demo.html:173-178 (.karten-label mit letter-spacing und Courier, 885 setzt dort brieftyp ein); 442 und 896 (ergAmpel ohne dir, computed direction 'ltr'); 1058 und 1083 (dir=auto, aber die Zeile beginnt mit 'Frist:', also ltr); 912-913 (p ohne dir, beobachtet: getAttribute('dir') = null); 186 (margin-right statt margin-inline-end). *Vorschlag:* #ergBrieftyp (oder .karten-label allgemein, sobald KI-Text darin steht): font-family:inherit oder eine Systemschrift, dazu letter-spacing:0 und text-transform:none. Die Schrift ist der eigentliche Fehler. Den Rest wie vorgeschlagen: Fachbegriff-<p> mit dir=auto, KI-Text in Ampel- und Fristzeile in ein eigenes <bdi>/<span dir=auto>, .todo::before mit margin-inline-end. Danach einmal auf dem eigenen Vorführ-Handy mit Arabisch ansehen. Aufwand eher unter einer Stunde.
+- **RA3 · 'Ergebnis aufs Handy mitnehmen': Telefonsätze kommen ohne Übersetzung an** (mittel, minuten, vor Termin) — Ob unter dem deutschen Telefonsatz die Bedeutung in der Muttersprache steht, hängt an der gespeicherten Sprache des Handys, nicht an der Sprache des Ergebnisses. Der Mitnehmen-QR (a=m) überträgt keine Sprache. Auf einem fremden Handy, das noch nie auf der Seite war, steht die Sprache auf 'de'. Der Ratsuchende bekommt also ein arabisches Ergebnis, aber die Anruf-Hilfe zeigt nur deutsche Sätze, die er nicht versteht. Bei der Vorführung fällt das nicht auf: Justins Handy hat durch den a=k-Schritt vorher schon 'ar' gespeichert. *Beleg:* demo.html:1133 (mitBedeutung = zielsprache() !== 'de'); 1383 (Mitnehmen-QR nur mit a, s, k, ohne l). Beobachtet auf einem frischen Handy-Profil mit arabischem Ergebnis: Sprachauswahl 'de', Anzahl .anruf-bed = 0, nur '„Guten Tag, mein Aktenzeichen ist AB-123/26.“' ohne arabische Zeile. *Vorschlag:* zeigeAnruf die Sprache der gerade angezeigten Version mitgeben: mitBedeutung = versionen[aktiveVersion].code !== 'de'. Zusätzlich l= in den Mitnehmen-QR schreiben und am Handy übernehmen wie bei a=k (Zeilen 1413-1416). Danach den Ablauf einmal mit einem Inkognito-Fenster am Handy testen.
+- **RA4 · Code vom Handzettel: Erklärung kommt auf Deutsch, obwohl das Handy auf Arabisch steht** (mittel, minuten, vor Termin) — Wer den Handzettel-QR (/demo?code=…) zu Hause scannt, löst den Code ein. Die Erklärungssprache bleibt aber auf 'Deutsch'. Die Seite fragt die Sprache des Handys nicht ab. Die Auswahl ist deutsch beschriftet ('Erklärung in dieser Sprache:') und wird leicht übersehen. Die erste Analyse aus dem Kontingent der MBE kommt dann auf Deutsch heraus, also verschwendet. *Beleg:* demo.html:563-568 (Rückfall immer 'de', navigator.language wird nirgends gelesen, per grep geprüft). Beobachtet mit Handy-Sprache Arabisch und ?code=TEST-AB23: navigator.language = 'ar', Sprachauswahl = 'de'. *Vorschlag:* Wie vorgeschlagen: In zielsprache() vor dem Rückfall navigator.languages durchgehen (Kürzel vor dem Bindestrich) und die erste Sprache nehmen, die es in SPRACH_NAMEN gibt. Die erkannte Sprache NICHT in localStorage speichern, nur verwenden. Dann gewinnt eine spätere Auswahl von Hand. Steht das Handy auf Deutsch, bleibt alles wie bisher.
+- **RA5 · Code abtippen: Leerzeichen statt Bindestrich, fehlender Bindestrich oder arabische Ziffern scheitern und zählen als Fehlversuch** (niedrig, minuten, vor Termin) — Wer 'MBE K7QX' (mit Leerzeichen) oder 'MBEK7QX' tippt, bekommt 'Diesen Code kennen wir nicht', also eine deutsche Meldung. Arabische und persische Handy-Tastaturen tippen Ziffern oft als ٧ bzw. ۷. Diese fallen durch die Prüfung [A-Z0-9-]. Jeder Fehlversuch zählt zur Sperre von 10 pro IP und Tag. In der Beratungsstelle teilen sich alle dasselbe WLAN, also dieselbe IP. Nach ein paar Tippfehlern ist das Einlösen für den Rest des Tages für alle gesperrt, auch über den QR-Link. Dazu kommt: Das Code-Feld steckt in einem eingeklappten, deutsch beschrifteten Bereich ganz unten im Kasten. *Beleg:* proxy/src/index.ts:719 (entfernt Leerzeichen, setzt aber keinen Bindestrich ein), 729 (Prüfung /^[A-Z0-9-]{4,40}$/, dann exakter Abgleich), 723-733 (Fehlversuch-Zähler pro IP). Lokal getestet: 'TEST AB23' → code_unbekannt, ' test-ab23 ' → ok. Hinweis: Mein Test hat den lokalen Zähler für ::1 heute um 1 erhöht (vorher 5). demo.html:372-377 (details am Ende). *Vorschlag:* Im Worker (und gleich auf der Seite): alles außer A-Z0-9 entfernen und den Bindestrich vor den letzten 4 Zeichen wieder einsetzen. Das deckt Leerzeichen und den fehlenden Bindestrich ab. Die Umwandlung arabischer Ziffern ist optional. Nicht dringend vor dem Termin, auf dem Handzettel steht der QR.
+- **RA6 · Ergebnis ist nach dem Schließen weg, es gibt keinen Weg zurück zur Erklärung** (mittel, stunden) — Das Ergebnis lebt nur in der offenen Seite. Es wird nirgends gespeichert und hat keinen Teilen- oder Speichern-Knopf. Nach a=k entfernt die Seite den QR-Teil aus der Adresse, nach a=m wird die Übergabe sofort gelöscht (einmalig, 15 Minuten). Wenn der Ratsuchende den Browser schließt, das Handy aufräumt oder die Seite neu lädt, sieht er wieder nur die deutsche Startansicht 'Probieren Sie es aus'. Die Erklärung, die To-do-Liste und die Telefonsätze sind weg. Ein Beraterinnen-Satz wie 'Schauen Sie es sich zu Hause noch mal an' lässt sich nicht einlösen. Nur den Kalender-Eintrag kann man behalten. *Beleg:* demo.html:856-863 (letzteDaten nur im Speicher), per grep: kein localStorage oder sessionStorage für Ergebnisse; 1507-1511 (Adresse wird bereinigt); 1440 (a=m löscht nach dem Abholen); 1437 ('gilt 15 Minuten und nur einmal'). *Vorschlag:* Vor dem Termin: Den Satz im Ablaufplan (Zeile 75) ehrlich machen, z. B. 'Das Ergebnis bleibt im Browser, solange die Seite offen ist. Wichtig ist der Kalender-Eintrag, der bleibt.' Nach dem Termin: zuerst einen Knopf 'Teilen/Speichern' mit navigator.share einbauen. Es wird nichts gespeichert, der Nutzer entscheidet selbst. Erst danach über localStorage nachdenken, dann mit Löschen-Knopf und einem Satz in der Datenschutzerklärung.
+- **RA7 · Am Handy liegt der Foto-Knopf über einen Bildschirm tief, ist grau und erklärt nicht, warum** (mittel, minuten, vor Termin) — Nach dem QR-Scan zeigt der erste Bildschirm nur den deutschen Werbekopf 'Probieren Sie es aus … 2 Analysen gratis', obwohl die Einrichtung zahlt. Das Verbunden-Banner beginnt bei 588 px, das Häkchen bei 816 px (unterer Rand) und der Foto-Knopf bei 1060 px. Er ist ausgegraut, bis man die deutsche Einwilligung anhakt. Antippen tut nichts, es kommt keine Erklärung. Zählung bis zum Foto: Link öffnen, scrollen, Häkchen, Knopf, Auswahl Kamera/Galerie (Android, weil kein capture-Attribut gesetzt ist), Foto, 'OK'. Das sind etwa 6-7 Schritte. Mit Beraterin daneben ist das machbar, allein ist es schwer. Beim Handzettel-Link liegt der Knopf sogar bei 1182 px. *Beleg:* Gemessen in Handy-Emulation 390×844: bannerTop 588, konsensTop 816, knopfTop 1060, knopfDisabled true; mit ?code=: knopfTop 1182. Code: demo.html:271-279 (Kopf), 284 ('2 Gratis-Analysen'), 331 (input ohne capture), 332 (disabled), 667. *Vorschlag:* Im Handy-Modus (handyModus/leseModus) nach dem Verbinden verbundenBanner.scrollIntoView() aufrufen und den Kopf ausblenden. Den Knopf nicht deaktivieren: Beim Tippen ohne Häkchen das Häkchen markieren und hinscrollen. capture nur bei a=k und dann den Galerie-Hinweis für diesen Fall ausblenden. Zusätzlich im a=k-Modus kaufBlock und codeTeil immer ausblenden, auch ohne w.
+- **RA8 · Fehlerfälle am Handy: deutsche Meldung, PC wartet bei Netzabbruch endlos, gleiches Foto nochmal auswählen tut nichts** (mittel, minuten, vor Termin) — (1) Alle Fehlermeldungen vom Server und von der Seite sind deutsch, z. B. 'Die Analyse ist fehlgeschlagen. Bitte versuchen Sie es mit einem neuen, gut beleuchteten Foto.' oder 'Verbindung fehlgeschlagen …'. (2) Reißt am Handy die Verbindung ab, landet der Fehler im catch-Zweig. Dieser meldet dem PC nichts. Der PC zeigt dann bis zu 15 Minuten '⏳ Das Handy hat fotografiert. Der Brief wird erklärt …', und die Beraterin merkt nicht, dass etwas schiefging. (3) Nach einem Fehler wie 'KI ausgelastet' wählt der Ratsuchende oft dasselbe Foto aus der Galerie. Das Datei-Feld wird nie zurückgesetzt, und Browser melden dieselbe Auswahl nicht erneut als Änderung. Es passiert dann nichts. *Beleg:* proxy/src/index.ts:284-474 (alle Meldungen deutsch). demo.html:828-833 (catch ohne meldeAnPc; im Gegensatz zu 764, wo der PC informiert wird), 751 (Status 'analyse' wird vorher gesendet), 1354-1357, 1337-1341 (Abbruch erst nach 15 Minuten). Per grep: kein dateiFeld.value = '' in der Datei, change-Listener in 678-680. Punkt (3) ist bekanntes Browser-Verhalten, auf einem echten Gerät nicht getestet. *Vorschlag:* Wie vorgeschlagen (meldeAnPc im catch, dateiFeld.value = '' vor dateiFeld.click()). Zusätzlich robuster am PC: Steht der Status länger als ca. 3 Minuten auf 'analyse', zeigt der PC 'Am Handy hat es wohl nicht geklappt, bitte dort neu versuchen'. Das hilft auch, wenn das Handy gar nichts mehr senden kann. Im Worker den Anthropic-fetch in try/catch setzen, damit immer JSON mit code 'ki' zurückkommt.
+- **RA9 · Älteres Android: Wird der Tab beim Öffnen der Kamera neu geladen, ist die Verbindung zum PC weg (Risiko)** (niedrig, stunden) — Auf Handys mit wenig Arbeitsspeicher kann Android den Browser-Tab beenden, während die Kamera-App offen ist. Danach lädt der Tab neu. Die Seite hat die Übergabe-Daten aber schon beim Start aus der Adresse gelöscht und nirgends behalten. Nach dem Neuladen ist das Handy nicht mehr verbunden. Es zeigt die normale Gratis-Demo (mit Kaufbereich), das Guthaben vom PC fehlt, und der PC wartet weiter. Für den Ratsuchenden sieht das aus wie 'kaputt'. *Beleg:* demo.html:1507-1511 (Adresse wird beim Start bereinigt), 609 und 1412 (handyModus inkl. Guthaben w nur im Speicher), 652-655 (ohne Guthaben wird der Kaufbereich gezeigt). Das Neuladen selbst ist geräteabhängig und hier nicht auf echter Hardware beobachtet. *Vorschlag:* sessionStorage für a/s/k/l/d/w wie vorgeschlagen, mit Zeitstempel und Ablauf nach 15 Minuten. Nicht vor dem Termin nötig. Für den Termin reicht der Hinweis an die Beraterinnen: 'Wenn das Handy die Verbindung verliert, einfach am PC neu auf „Lieber mit dem Handy fotografieren“ tippen.'
+
+### Live-Vorführung am 29.10.
+_Der Ablaufplan passt im Großen zum Code: Die drei Knöpfe heißen genau so, und die Aufteilung (Laptop zeigt zuerst Deutsch, Handy zuerst Arabisch, dazu ein Umschalter) ist richtig gebaut. Drei Dinge können die Vorführung aber kippen. Erstens ist der Kern der Vorführung, die zweisprachige Analyse übers Handy, noch nie mit echter KI gelaufen und auch nicht deployed. Zweitens zeigt die Ampel für den Musterbrief vor 12 Uhr Gelb mit „Noch 8 Tage“ statt Rot. Drittens kommt das Ergebnis nur über das Handy auf den Laptop, das Handy darf in der Wartezeit also nicht in die Sperre gehen. In 10–15 Minuten ist das machbar, die 5 Minuten für die Live-Vorführung sind aber knapp. Für die Beraterinnen am PC ist es bequem. Für Ratsuchende am Handy ist es noch umständlich: deutsche Bedienung, eine deutsche Einwilligung zum Anhaken und mehrere Schritte._
+
+- **LI1 · Kern der Vorführung nie mit echter KI getestet, nicht deployed, Prüfskript prüft das Neue nicht** (blocker, stunden, vor Termin) — Vorgeführt wird genau der Weg, der noch nie gelaufen ist: Laptop zeigt den QR-Code, das Handy fotografiert, dann zweisprachige Analyse (Sonnet auf Deutsch, danach Übersetzung mit Haiku). Lokal gibt es keinen KI-Schlüssel, und live läuft noch der alte Stand ohne /code und /uebergabe. Der Ablaufplan setzt „Deploy erledigt“ erst auf den Vorabend. Bleibt dann ein Fehler übrig, ist keine Zeit mehr zum Reparieren. Außerdem prüft „npm run pruefung alles grün“ die neuen Funktionen gar nicht. Wird nur die Webseite deployed und nicht der Worker, sieht man live den Handy-Knopf, aber die Übergabe geht nicht. *Beleg:* ablaufplan.html:113 (Deploy erst „Am Vorabend“). tools/pruefung.js: Kein Test ruft /code oder /uebergabe auf (grep findet nur hole(BASIS + '/demo') in Zeile 175). index.ts:479-484 (Übersetzungsweg, lokal ohne Schlüssel nicht ausführbar). demo.html:1326 und uebergabe.js:16 (Seite fragt live den Worker unter /uebergabe/ ab). *Vorschlag:* Wie vorgeschlagen: bis spätestens Mo 26.10. zuerst den Worker deployen, dann die Webseite, dann 2–3 komplette Durchläufe auf dem Live-System (gleiche Geräte, Hotspot, gedruckter Musterbrief, Arabisch, Zeit stoppen, Screenshots). Dazu von Hand prüfen: falscher Code → „Diesen Code kennen wir nicht“, Laptop zeigt nach dem Scan „Handy verbunden“, am Ende zwei Sprachknöpfe „Deutsch“ und „العربية“ (nicht zweimal „Deutsch“). Später einen kleinen Test für /code und /uebergabe in npm run pruefung ergänzen.
+- **LI2 · Ampel zeigt am 29.10. vormittags Gelb mit „Noch 8 Tage“, nicht Rot** (hoch, minuten, vor Termin) — Die Web-Ampel rechnet vom jetzigen Zeitpunkt bis 12:00 Uhr am Zieltag und rundet auf. Für den Termin am 05.11.2026 kommt deshalb vor 12 Uhr „8 Tage“ heraus, also Gelb. Erst ab 12 Uhr sind es 7 Tage und damit Rot. Der Ablaufplan verspricht „rote Ampel (Termin in 7 Tagen)“. Findet die Präsentation vormittags statt, stimmt der wichtigste Moment nicht. Dazu kommt: Die App zählt anders, dort ist ein Abstand von genau 7 Tagen Gelb. Der Handzettel sagt dagegen „Rot bei 7 Tagen oder weniger“. *Beleg:* demo.html:843-846 (Math.ceil(...T12:00:00 - jetzt), rot bei ≤ 7). Mit derselben Formel nachgerechnet (TZ=Europe/Berlin): 29.10. 09:00 und 11:59 → 05.11. = 8 Tage, GELB. 29.10. 12:01 und 15:00 → 7 Tage, ROT. App: src/utils/ampel.ts:22-27 und 113 (Kalendertage, rot nur bei < 7). ablaufplan.html:74, handzettel.html:115, musterbrief-auslaenderbehoerde.html:112. *Vorschlag:* Besser die Formel reparieren als nur den Brief ändern, denn ein Deploy kommt sowieso. In demo.html ampel() wie tageBis() in ampel.ts in Kalendertagen rechnen (heute 00:00 bis Zieltag 00:00, Math.round). Dann gilt am 29.10. für den 05.11. zu jeder Uhrzeit „Noch 7 Tage“ und Rot, und am Fristtag erscheint „HEUTE“. Zusätzlich darf man den Termin im Musterbrief auf Dienstag, 03.11.2026, 10:30 legen, das ist dann doppelt sicher. Danach neu drucken und im Ablaufplan „Termin in 7 Tagen“ durch „Termin nächste Woche“ ersetzen.
+- **LI3 · Den „Vorführ-Code“ gibt es nirgends, und der MBE-Code kann vor dem Auswertungstermin ablaufen** (mittel, minuten, vor Termin) — Der Ablaufplan setzt einen eingelösten Vorführ-Code voraus. In der Checkliste für den Vorabend steht aber nur der MBE-Code. Ohne Code am Laptop enthält der QR-Code kein Guthaben, und das Handy fällt in die Gratis-Demo. Nach zwei Übungsläufen mit demselben Handy blendet die Seite den Hochladen-Bereich aus und meldet „Ihre 2 Gratis-Analysen sind verbraucht“. Dann scheitert die Vorführung. Zweites Problem: „--monate 1“ rechnet ab dem Tag, an dem der Code angelegt wird. Legt Justin den MBE-Code heute an, endet er am 22.11., also vor dem Auswertungstermin am 26.11. Drittens ist der Handzettel noch ohne Code gedruckt: Dort steht „wird beim Termin eingetragen“, und der QR-Code führt nur auf /demo. *Beleg:* ablaufplan.html:70 und 123 („Vorführ-Code eingelöst“) gegen ablaufplan.html:114 (nur „MBE-Code angelegt“). demo.html:1301 (Guthaben kommt nur mit hatGuthaben() in den QR-Code). demo.html:657-661 (ab 2 Gratis-Analysen wird die Eingabe gesperrt). tools/einrichtungs-code.js plusMonate() rechnet ab heute. handzettel.html:190 (CODE = ''). handzettel.png zeigt „wird beim Termin eingetragen“. *Vorschlag:* Den Vorführ-Code ausdrücklich in die Checkliste „Am Vorabend“ schreiben und vor den Übungsläufen anlegen. Beide Codes mit festem Enddatum anlegen (Option --bis gibt es, einrichtungs-code.js:81), z. B. MBE mit --briefe 100 --bis 2026-11-30 und VORF mit --briefe 30 --bis 2026-11-30. Danach den MBE-Code in handzettel.html eintragen, das PDF neu erzeugen und prüfen, dass der QR-Code auf /demo?code=MBE-… zeigt.
+- **LI4 · Das Ergebnis kommt nur über das Handy auf den Laptop, das Handy darf in der Wartezeit nicht sperren** (mittel, minuten, vor Termin) — Der Laptop bekommt das Ergebnis nicht vom Server, sondern nur, wenn das Handy es nach der Analyse weiterschickt. Das Handy muss also die ganze Wartezeit mit offener Seite im Vordergrund bleiben. Bei vielen iPhones geht der Bildschirm nach 30 Sekunden aus, im Stromsparmodus immer. Die Analyse dauert aber wahrscheinlich länger. Ob Safari die laufende Anfrage nach dem Sperren noch zu Ende bringt, ist nicht getestet. Wenn nicht: Das Handy zeigt „Verbindung fehlgeschlagen“, der Laptop bleibt bei „Der Brief wird erklärt …“ hängen, und die Analyse ist trotzdem schon abgebucht. Ähnlich beim Laptop: Geht er in den Ruhezustand, hört er auf nachzufragen. *Beleg:* demo.html:753-758 (Handy wartet auf /demo). demo.html:806-809 (erst danach meldeAnPc(..., 'ergebnis')). demo.html:1335-1358 (der PC fragt nur das Übergabe-Fach ab, alle 1,5 s). index.ts:444-446 (Guthaben wird auf dem Server abgezogen, egal ob das Handy die Antwort noch bekommt). ablaufplan.html:124 nennt nur „Handy entsperrt“, nicht die automatische Sperre. *Vorschlag:* In „Kurz vor dem Termin“ ergänzen: Am iPhone Einstellungen → Anzeige & Helligkeit → Automatische Sperre „Nie“ und den Stromsparmodus aus. Das Handy während der Analyse in der Hand behalten und nicht in eine andere App wechseln. Am Mac den Ruhezustand verhindern, z. B. im Terminal mit „caffeinate -d“. In den Notfallplan schreiben: „Laptop hängt, aber das Handy zeigt das Ergebnis → einfach das Handy zeigen.“
+- **LI5 · Beratungs-PC ohne eingelösten Code: Ratsuchende landen in der Gratis-Demo mit Kaufangebot** (hoch, minuten, vor Termin) — Das „Foto mit dem Handy“ läuft nur dann über das Kontingent der Einrichtung, wenn der Code vorher am Beratungs-PC eingelöst wurde. Sonst steckt im QR-Code kein Guthaben. Das Handy der ratsuchenden Person nutzt dann ihre 2 Gratis-Analysen, fragt beim zweiten Mal nach der E-Mail und zeigt sofort den Abschnitt „Guthaben kaufen“ mit 2,99 €. Das widerspricht „Ratsuchende zahlen nichts“. Auf dem Handzettel steht nur „Code für Ihre Ratsuchenden“. Dass der Code auch am PC der Beraterin eingegeben werden muss, steht nirgends. Gerade die als NEU beworbene Funktion „Beratung am PC“ geht im Testmonat so leicht schief. *Beleg:* demo.html:1301 (w nur mit hatGuthaben()). demo.html:612-615 (Handy ohne Guthaben nutzt die Gratis-Stufe). demo.html:652-655 (kaufBlock wird in der Gratis-Stufe immer gezeigt). handzettel.html:125-128 und 173. *Vorschlag:* Im Termin, Abschnitt 9–11', den Code gleich live an einem PC der Beraterinnen einlösen („Ich richte es Ihnen sofort ein, eine Minute“). Das wirkt bequem und vermeidet den Fehler. Auf den Handzettel einen Satz setzen: „Einmal am Beratungs-PC unter ‚Sie haben einen Code von einer Beratungsstelle?‘ eingeben, dann ist auch ‚Mit dem Handy fotografieren‘ kostenlos.“ Danach den Handzettel neu erzeugen.
+- **LI6 · Ampel-Zeile verbindet das Termin-Datum mit der Aufgabe aus der Frist** (mittel, minuten, vor Termin) — Die Ampel nimmt das früheste Datum, beim Musterbrief also den Termin am 05.11. Dahinter hängt sie aber immer die Aufgabe aus der Frist. Heraus kommt so etwas wie „Noch 7 Tage Zeit (05.11.2026) · Unterlagen einreichen“, obwohl die Unterlagen bis zum 12.11. reichen. Beraterinnen arbeiten jeden Tag mit Fristen und sehen das sofort. Das kostet Vertrauen, ausgerechnet beim Punkt „Frist erkannt“. *Beleg:* demo.html:839-842 (Frist- und Termin-Datum werden gemischt und sortiert, das erste gewinnt). demo.html:849 (Text mit daten[0]). demo.html:894-896 (hängt immer frist.aktion an). Musterbrief: Termin 05.11. (Zeile 112), Frist 12.11. (Zeile 109). *Vorschlag:* In ampel() mitschreiben, welches Datum gewonnen hat, und „Termin am 05.11.“ bzw. „Frist bis 12.11.“ anzeigen. frist.aktion nur anhängen, wenn das früheste Datum wirklich die Frist ist. Das ist eine kleine Änderung. Sonst im Vortrag selbst erklären: „Die Ampel richtet sich nach dem nächsten Datum, hier dem Termin.“
+- **LI7 · Am Handy viele Schritte, Bedienung und Einwilligung nur auf Deutsch** (mittel, minuten, vor Termin) — Nach dem Scannen öffnet sich am Handy die ganze Demo-Seite. Oben steht „Probieren Sie es aus … 2 Analysen gratis“, der Hinweis „Mit dem Computer verbunden“ liegt weiter unten, und die Seite scrollt nicht von selbst dorthin. Danach muss man die Einwilligung anhaken (vorher bleibt der Knopf grau), auf „Brief auswählen“ tippen, „Foto aufnehmen“ wählen, fotografieren und „Foto verwenden“ antippen. Im Ablaufplan steht nur „Musterbrief fotografieren“. Für Ratsuchende sind die Einwilligung (Daten an Anthropic in den USA), alle Kartentitel, der Kalender-Knopf, die Ampel („Noch 7 Tage Zeit“) und der Hinweis „ersetzt keine Rechtsberatung“ auf Deutsch. Nur der Inhalt erscheint auf Arabisch. Beraterinnen der Migrationsberatung fragen sehr wahrscheinlich: „Versteht mein Klient, was er da ankreuzt?“ *Beleg:* demo.html:272-284 (Kopf und „2 Gratis-Analysen“, auch im Handy-Modus sichtbar). demo.html:306-316 (Einwilligung nur auf Deutsch). demo.html:667 (Knopf erst nach dem Häkchen aktiv). demo.html:1411-1422 (Handy-Modus ohne Scrollen zum Banner). demo.html:446-473 und 485-488 (deutsche Titel). demo.html:847-849 (Ampeltext fest auf Deutsch). *Vorschlag:* Vor dem Termin die genauen Handy-Schritte in den Ablaufplan schreiben und üben: scrollen → Häkchen → Brief auswählen → Foto aufnehmen → Foto verwenden. Klein und schnell zu bauen: im Handy-Modus mit verbundenBanner.scrollIntoView() zum Banner springen. Für die Frage eine ehrliche Antwort bereithalten: „Inhalt in der Muttersprache, die Bedienknöpfe und die Einwilligung übersetze ich als Nächstes.“ Danach den Text der Einwilligung und die Kartentitel in die 27 Sprachen übersetzen, z. B. über texte.js.
+- **LI8 · Wartezeit nicht gemessen, „etwa eine Minute“ ist für zwei KI-Aufrufe nacheinander gewagt** (mittel, minuten, vor Termin) — Bei der zweisprachigen Analyse laufen zwei KI-Aufrufe nacheinander: erst Sonnet mit dem Bild, danach Haiku mit der ganzen Antwort. Der Server antwortet erst, wenn beide fertig sind. Dazu kommen das Hochladen über den Hotspot und bis zu 1,5 s, bis der Laptop das nächste Mal nachfragt. Ablaufplan, Handzettel und Seite versprechen „etwa“ bzw. „bis zu einer Minute“. Wie lange es wirklich dauert, hat niemand gemessen, denn lokal gibt es keinen Schlüssel. Außerdem: Scheitert nur die Übersetzung, zeigt das Handy Deutsch statt Arabisch, und im Umschalter steht zweimal „Deutsch“. Ausgerechnet die arabische Fassung würde dann in der Vorführung fehlen. *Beleg:* index.ts:395-419 (Sonnet) und danach index.ts:479-484 (Haiku, nacheinander). Bei Fehlschlag gilt ausgabeSprache = 'de', während analyse_de weiter mitgeschickt wird. demo.html:857-861 legt dann zwei Fassungen mit dem Code 'de' an. demo.html:383 („bis zu einer Minute“). ablaufplan.html:72. handzettel.html:103. demo.html:1326 (Abfrage alle 1,5 s). *Vorschlag:* Die Wartezeit in den Übungsläufen stoppen (siehe LI1). Im Vortrag lieber „ein bis zwei Minuten“ sagen. Den Datenschutz-Teil fest in die Wartezeit legen, nicht nur im Notfall: Dann ist die Wartezeit eingeplant und nicht peinlich. Erscheint zweimal „Deutsch“, ist die Übersetzung gescheitert. Dann ruhig sagen „Hier hat die Übersetzung gehakt“ und die Screenshots zeigen.
+- **LI9 · Kalender-Knopf ist ein Datei-Download: „Ein Tipp genügt“ ist ungetestet, am Laptop landet der Eintrag im eigenen Kalender** (niedrig, minuten, vor Termin) — „In meinen Kalender eintragen“ erzeugt eine .ics-Datei und lädt sie herunter. Am Laptop landet die Datei im Download-Ordner. Beim Öffnen trägt der Mac den Termin in Justins eigenen Kalender ein, vor Publikum. Am Handy kommen wahrscheinlich je nach Browser Rückfragen wie Laden, Öffnen und Hinzufügen. Der Handzettel verspricht „Ein Tipp genügt, das Handy erinnert 3 Tage und 1 Tag vorher“. Wie viele Tipps es auf iPhone und Android wirklich sind, ist nicht dokumentiert. *Beleg:* demo.html:1088-1097 (Blob-Download mit link.download = 'BehoerdenKlar-Termin.ics'). handzettel.html:118-119. ablaufplan.html:74 (Vorführen von „In meinen Kalender“ ohne Gerät). *Vorschlag:* Den Kalender-Knopf nur am Handy vorführen, nicht am Laptop. Vorher auf dem eigenen iPhone und auf einem Android-Handy testen und die Zahl der Tipps zählen. Danach den Handzettel, falls nötig, auf „Mit einem Tipp in den Kalender, das Handy erinnert …“ oder „Mit wenigen Tipps …“ anpassen.
+- **LI10 · Ablaufplan nachschärfen: Mitnehmen-Schritt doppelt, QR-Code läuft ab, Fachbegriff nicht sicher** (niedrig, minuten, vor Termin) — 1) Nach dem Handy-Foto hat das Handy das Ergebnis schon. Danach noch „Ergebnis aufs Handy mitnehmen“ mit demselben Handy zu zeigen, wirkt doppelt und kostet einen zweiten Scan. Die Seite liest den Teil hinter dem # nur beim Laden. Öffnet der Browser den neuen Link im schon offenen Tab nur als Sprung auf derselben Seite, passiert nichts. Das ist nicht getestet. 2) Der QR-Code für das Handy läuft 15 Minuten nach dem Klick ab. Wer ihn vor dem Gespräch schon „bereitlegt“, sieht mitten in der Vorführung „Der QR-Code ist abgelaufen“. 3) Ob „Fiktionsbescheinigung“ wirklich unter den Fachbegriffen auftaucht, entscheidet die KI. Fest versprechen lässt sich das nicht. *Beleg:* demo.html:1507-1516 (ausAdresse/pruefeUebergabe nur beim Start, kein hashchange-Handler). demo.html:1316 und 1337-1341 (15-Minuten-Grenze ab dem Klick). index.ts:140-147 (fachbegriffe frei von der KI gewählt). ablaufplan.html:74-75. *Vorschlag:* Den Mitnehmen-QR von einer Beraterin mit ihrem eigenen Handy scannen lassen. Das ist ein schöner Moment zum Mitmachen und umgeht das Tab-Problem. Mit dem Musterbrief ist das unbedenklich. In den Ablaufplan schreiben: „QR erst live erzeugen, bei ‚abgelaufen‘ einfach neu klicken.“ Beim Fachbegriff den zeigen, der tatsächlich erscheint.
+- **LI11 · „Steht vor dem Hochladen auf der Seite“ stimmt nur zur Hälfte** (niedrig, minuten, vor Termin) — Ablaufplan und Handzettel sagen, die Seite nenne schon vor dem Hochladen „löscht nach spätestens 30 Tagen, kein Training“. In der Einwilligung auf der Demo-Seite steht aber nur „Es wird dort nicht dauerhaft gespeichert“. Die 30 Tage und das fehlende Training stehen nur in der Datenschutzerklärung. Eine aufmerksame Beraterin kann das während der Vorführung nachlesen. *Beleg:* demo.html:309-313 (Text der Einwilligung). ablaufplan.html:82 und 137. handzettel.html:152. datenschutz.html:64-65 und 115 (dort stehen die 30 Tage und das fehlende Training). *Vorschlag:* Entweder einen halben Satz in die Einwilligung einfügen („Anthropic löscht es nach spätestens 30 Tagen und nutzt es nicht zum Training.“). Oder im Vortrag sagen: „Das steht in der Datenschutzerklärung, die vor dem Hochladen verlinkt ist.“
+
+### Datenschutz des Trägers
+_Technisch ist BehördenKlar datensparsam gebaut, sparsamer als die meisten Werkzeuge, die Beratungsstellen sonst nutzen. Briefe werden nicht gespeichert, die Übergabe per QR ist wirklich Ende-zu-Ende verschlüsselt, und der Weg über den Einrichtungs-Code kommt ohne E-Mail und ohne IP-Zähler aus. Die Lücken liegen im Papier, nicht im Code. Erstens ist nicht geklärt, wer verantwortlich ist, wenn die Beraterin am Dienst-PC den Brief einer Klientin hochlädt. Zweitens passt die Einwilligung nicht zur Beratungssituation: Sie ist nur auf Deutsch, spricht von „mein Brief-Foto“ und wird nach dem ersten Brief nicht zurückgesetzt. Drittens fehlen die Unterlagen, die ein Träger-DSB vor einem Test sehen will: AVV-Entwurf, technische und organisatorische Maßnahmen (TOMs) und ein aktuelles Datenschutz-Blatt. Realistisch: Die Beraterinnen können am 29.10. Ja sagen wollen, müssen aber an ihren Träger bzw. Datenschutzbeauftragten verweisen. Bringt Justin eine kurze Datenschutz-Mappe mit und schlägt er als Standard vor, dass die Klientin mit ihrem eigenen Handy fotografiert und selbst einwilligt (a=k), steigen die Chancen auf einen schnellen Start deutlich._
+
+- **DA1 · Ungeklärt: Wer ist verantwortlich, wenn die Beraterin am Dienst-PC hochlädt?** (hoch, tag, vor Termin) — Die Datenschutzerklärung kennt nur eine Rolle: Webklar ist verantwortlich, die Rechtsgrundlage ist die Einwilligung des Nutzers selbst. Lädt aber die Beraterin im Dienst den Brief einer Klientin hoch, nutzt der Träger das Werkzeug für seine Beratung. Ein Träger-DSB wird dann fast sicher sagen: Wir sind verantwortlich, Webklar arbeitet in unserem Auftrag, also brauchen wir einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Den gibt es nicht. Der Handzettel sagt sogar „Kein Vertrag“. Dazu kommen typische Rückfragen: Beraterinnen mit staatlicher Anerkennung unterliegen der Schweigepflicht (§ 203 StGB), dann wird eine Verschwiegenheitsverpflichtung des Dienstleisters verlangt. Ist der Träger kirchlich (Diakonie: DSG-EKD, Caritas: KDG), gelten eigene Datenschutzgesetze mit eigenen Vorgaben für den AVV. Wer Träger der MBE Donnersberg ist (mbe@fid-donnersberg.de), ist in den Unterlagen nicht festgehalten. *Beleg:* webseite/datenschutz.html:35-42 und 68-75 (nur Webklar als Verantwortlicher, nur Einwilligung des Nutzers); marketing/praesentation-mbe/handzettel.html:171 („Kein Vertrag, endet von selbst“); rechtliches/ enthält keinen AVV-Entwurf für Einrichtungen; marketing/outreach-september.md:20 (Träger nicht genannt) *Vorschlag:* Vor dem Termin: (a) Anrufen und fragen, wer Träger der MBE ist und ob es eine eigene AVV-Vorlage gibt. (b) Eine kurze schriftliche Aussage zur Rolle mitbringen (eine halbe Seite): „Lädt die Beratungsstelle selbst hoch, arbeiten wir als Auftragsverarbeiter. Einen AVV mit Verschwiegenheitsklausel und Cloudflare/Anthropic als Unterauftragsverarbeitern stellen wir auf Wunsch bereit.“ (c) Für den Testmonat empfehlen, dass die Klientin selbst am eigenen Handy fotografiert und einwilligt (a=k). Dabei offen sagen, dass das Ergebnis trotzdem am PC der Stelle erscheint. Den vollständigen AVV-Entwurf (nach GDD- oder Bitkom-Muster) gleich nach dem Termin schicken, spätestens bevor echte Briefe am Dienst-PC hochgeladen werden. Ein fertiger AVV in einem Tag ist für einen Nicht-Juristen ehrgeizig. Wichtiger ist, dass er vor dem ersten echten Brief vorliegt.
+- **DA2 · Häkchen-Text passt nicht zur Beratung und gilt nach dem ersten Brief weiter** (hoch, stunden, vor Termin) — Der Text lautet „Ich bin einverstanden, dass MEIN Brief-Foto …“. Am Dienst-PC setzt die Beraterin das Häkchen, ist aber nicht die betroffene Person und kann nicht für die Klientin einwilligen. Außerdem nennt der Text keine besonderen Daten (Gesundheit, Herkunft o. Ä.). Art. 9 DSGVO verlangt aber eine ausdrückliche Einwilligung, und gerade diese Daten stehen in Briefen von Ausländerbehörde, Krankenkasse oder Jobcenter. Dazu kommt: Das Häkchen wird nie zurückgesetzt. Mit Einrichtungs-Code öffnet sich nach jeder Analyse sofort wieder das Eingabefeld, das Häkchen ist noch gesetzt. Die zweite, dritte und vierte Klientin des Tages wird also gar nicht mehr gefragt. *Beleg:* webseite/demo.html:306-316 (Text „mein Brief-Foto“, keine besonderen Daten genannt); demo.html:667 (einzige Stelle mit konsens, nirgends wird es zurückgesetzt); demo.html:936-940 (bei Guthaben öffnet sich die Eingabe nach dem Ergebnis sofort wieder) *Vorschlag:* Im Einrichtungs-Modus einen eigenen Text zeigen, z. B.: „Die ratsuchende Person ist einverstanden, dass ihr Brief (der Angaben z. B. zu Gesundheit, Herkunft oder Aufenthalt enthalten kann) zur Erklärung an BehördenKlar und den KI-Dienst Anthropic (USA) geschickt wird.“ Nach jeder Analyse `konsens.checked = false` setzen und den Knopf sperren. Zusätzlich für die Beratungsstelle eine einseitige Papier-Einwilligung zum Unterschreiben anbieten, die sie mit ihrer üblichen Schweigepflichtentbindung abheften kann.
+- **DA3 · Einwilligung nur auf Deutsch, auch für Klientinnen, die kein Deutsch lesen** (mittel, stunden, vor Termin) — Eine Einwilligung zählt nur, wenn die Person versteht, wozu sie Ja sagt (Art. 4 Nr. 11 und Art. 7 Abs. 2 DSGVO: klare, einfache Sprache). Die Zielgruppe der MBE liest oft wenig Deutsch. Trotzdem ist die Demo-Seite samt Häkchen-Text komplett deutsch, auch im a=k-Ablauf, in dem die Klientin am eigenen Handy zustimmt und die Zielsprache (z. B. Arabisch) schon bekannt ist. Die 27 Sprachseiten erwähnen weder Anthropic noch die USA und verlinken direkt auf die deutsche Demo. Ein DSB wird fragen: „Wie willigt eine Klientin ein, die nur Dari spricht?“ *Beleg:* webseite/demo.html:2 (lang=de) und 306-316 (fester deutscher Text, keine Übersetzungslogik im Skript); grep „Anthropic“ in ar.html, tr.html, uk.html, fa.html: jeweils 0 Treffer; ar.html:286 verlinkt auf /demo?sprache=ar; demo.html:1411-1416 (a=k setzt nur die Ergebnis-Sprache, nicht den Text der Seite) *Vorschlag:* Den 2-3 Sätze langen Häkchen-Text in der gewählten Zielsprache unter dem deutschen Text einblenden. Zuerst Arabisch, Farsi/Dari, Ukrainisch, Türkisch, Russisch, den Rest danach. Maschinelle Übersetzung möglichst von einer Muttersprachlerin gegenlesen lassen (z. B. beim Auswertungstermin die Beraterinnen fragen). Bis dahin beim Termin offen sagen, dass die Beraterin den Hinweis mündlich erklären muss. Die Papier-Einwilligung aus DA2 kann diese Lücke für den Testmonat überbrücken.
+- **DA4 · Zu absolute Aussagen auf Handzettel und Spickzettel (30 Tage, „Server sieht nichts“)** (mittel, minuten, vor Termin) — (a) „löscht nach spätestens 30 Tagen“ stimmt so nicht. Laut Anthropics eigener Datenschutz-Hilfeseite ist 30 Tage der Normalfall, aber bei Verdacht auf Missbrauch (automatisch markiert) bleiben Ein- und Ausgaben bis zu 2 Jahre gespeichert, dazu gibt es gesetzliche Ausnahmen. (b) „unser Server sieht nichts“ gilt nur für die QR-Übergabe. Das Brief-Foto selbst läuft im Klartext (nur über TLS geschützt) durch den Worker zu Anthropic. Der Satz im Spickzettel „Zwischen PC und Handy ist alles Ende-zu-Ende verschlüsselt“ kann als „der Brief ist Ende-zu-Ende verschlüsselt“ verstanden werden. Ein DSB fragt dann: „Aber die KI liest den Brief doch?“ Das schadet der Glaubwürdigkeit, die der „ehrlich“-Kasten aufbauen soll. *Beleg:* marketing/praesentation-mbe/handzettel.html:150 und 152; ablaufplan.html:82 und 137; rechtliches/datenschutz-factsheet.md:30; webseite/datenschutz.html:64-65 und 115; Worker reicht das Bild im Klartext weiter: proxy/src/index.ts:390-419; Anthropic-Hilfeseite „How long do you store my organization's data“ (privacy.claude.com, Artikel 7996866): Ausnahme „inputs and outputs for up to 2 years“ bei markierten Verstößen *Vorschlag:* Umformulieren und Handzettel-PDF neu erzeugen: „Anthropic löscht Anfragen in der Regel nach 30 Tagen (länger nur bei Verdacht auf Missbrauch) und nutzt sie nicht zum Training.“ Und: „Den Brief selbst muss die KI lesen. Er geht verschlüsselt übertragen über unseren Server zu Anthropic und wird bei uns nicht gespeichert. Die Übergabe zwischen PC und Handy ist zusätzlich Ende-zu-Ende verschlüsselt.“ Dieselbe Formulierung in Datenschutzerklärung und Factsheet übernehmen.
+- **DA5 · Drittland-Grundlage und Vertragspartner nicht belegt** (mittel, stunden, vor Termin) — Datenschutzerklärung und AVV-Nachweis stützen die Übermittlung an Anthropic auch auf das EU-U.S. Data Privacy Framework (DPF). Einen Beleg dafür gibt es in den Unterlagen nicht. Anthropics eigene Zertifizierungsseite nennt ISO 27001, ISO 42001 und SOC 2, aber kein DPF, und die Websuche brachte keinen DPF-Eintrag (unbestätigt, nicht widerlegt). Die DPA-PDFs sind nicht gesichert (offener Punkt im Nachweis). Außerdem steht im AVV-Nachweis als Verantwortlicher „Justin Klein“ mit einer privaten Gmail-Adresse als Kontoinhaber, in der Datenschutzerklärung dagegen die Webklar GbR. Ein DSB fragt: „Wer genau hat den Vertrag mit Anthropic geschlossen?“ *Beleg:* rechtliches/avv-nachweis.md:9-12 (Justin Klein, einkauf.justin@gmail.com), :20 (DPF ohne Quelle), :35-36 (DPA-PDFs noch nicht abgelegt); webseite/datenschutz.html:37-38 (Webklar GbR) und :107-110 („DPF bzw. SCC“) *Vorschlag:* In datenschutz.html:107-110, im Factsheet und im AVV-Nachweis für Anthropic nur „EU-Standardvertragsklauseln (Bestandteil des Anthropic-DPA)“ schreiben. Für Cloudflare darf das DPF stehen bleiben. Einen Eintrag nur dann ergänzen, wenn er auf dataprivacyframework.gov wirklich zu finden ist. Die DPA-PDFs ablegen und die Organisation in beiden Konten auf „Webklar GbR“ stellen. Das dauert eher Minuten als Stunden.
+- **DA6 · Unterlagen für den Träger fehlen, das vorhandene Datenschutz-Blatt ist veraltet** (mittel, tag, vor Termin) — Vor einem Test mit echten Klientendaten verlangt ein Träger-DSB typischerweise: (1) eine Beschreibung der Datenflüsse, (2) die Liste der Unterauftragsverarbeiter, (3) die TOMs, (4) einen AVV oder eine klare Rollenaussage, (5) einen Textbaustein für sein Verarbeitungsverzeichnis, (6) Angaben für seine Datenschutz-Folgenabschätzung (KI, Art.-9-Daten, verletzliche Personen: eine solche Prüfung ist hier naheliegend). Davon gibt es nur das Factsheet, und das ist vom 15.07.: „9 weitere Sprachen“, die alte Adresse behoerdenklar.pages.dev, kein Wort zu Web-Demo, Einrichtungs-Code oder QR-Übergabe. Im Spickzettel fehlen die Fragen „Brauchen wir einen AVV?“ und „Wer ist verantwortlich?“. Brevo (Kauf-Mails, Warteliste) fehlt im AVV-Nachweis, obwohl es genutzt wird. *Beleg:* ls rechtliches/: nur avv-nachweis.md, datenschutz-factsheet.md, datenschutzerklaerung.md, docx; repoweite Suche nach TOM/Verarbeitungsverzeichnis/Folgenabschätzung/AVV-Vertrag: 0 Treffer; datenschutz-factsheet.md:4, 9 und 79 (Stand 15.07., 9 Sprachen, pages.dev); ablaufplan.html:137ff. (keine AVV-Frage); avv-nachweis.md:39-40 (Brevo als „später“), aber proxy/src/index.ts:562-578 und demo.html:509 nutzen Brevo *Vorschlag:* Vor dem Termin nur das Nötigste: ein aktualisiertes Factsheet auf 1-2 Seiten (Datenfluss Web-Demo, Code und QR-Übergabe, Unterauftragsverarbeiter Cloudflare und Anthropic, die korrigierten Sätze aus DA4/DA5, die Rollenaussage aus DA1). Das alte Factsheet bis dahin nicht weitergeben. Brevo in den AVV-Nachweis aufnehmen. TOMs in Stichpunkten, einen Absatz fürs Verarbeitungsverzeichnis und den AVV-Entwurf beim Termin anbieten („bekommt Ihr Datenschutzbeauftragter von mir“) und innerhalb weniger Tage nachliefern. In den Spickzettel die Fragen „Brauchen wir einen AVV?“ und „Wer ist verantwortlich?“ mit Antwort aufnehmen.
+- **DA7 · Live-Datenschutzerklärung kennt Einrichtungs-Code und QR-Übergabe noch nicht** (niedrig, minuten, vor Termin) — Die neuen Abschnitte 9a (Einrichtungs-Code) und 9b (Übergabe Handy/PC) stehen nur in der lokalen Datei. Live ist die Fassung vom 18.08.2026. Wird nur der Worker deployt oder die Webseite vergessen, laufen die neuen Funktionen ohne passende Datenschutzerklärung. Klickt eine Beraterin bei der Vorführung auf „Datenschutzerklärung“, findet sie nichts zum QR-Code. *Beleg:* Beobachtet: curl https://behoerdenklar.de/datenschutz zeigt „Stand: 18.08.2026“ und die Überschriften 1–12 ohne 9a/9b; lokal webseite/datenschutz.html:32 (Stand 22.10.2026), :218-257 (9a, 9b) *Vorschlag:* Nach dem Deploy der Webseite kurz live prüfen, ob „9b. Übergabe zwischen Handy und Computer“ zu sehen ist. Optional einen Prüfpunkt in tools/pruefung.js aufnehmen (auf der Live-Datenschutzseite nach „9b.“ suchen).
+- **DA8 · Gemeinsamer Dienst-PC: Das Ergebnis der vorigen Klientin bleibt auf dem Bildschirm** (mittel, stunden) — Nach einer Analyse bleibt die Erklärung (Name der Behörde, Aktenzeichen, Frist, Inhalt) sichtbar, bis der nächste Brief sie ersetzt oder die Seite neu geladen wird. Einen Knopf „Fertig, vom Bildschirm löschen“ gibt es nicht. Die nächste Person am Schreibtisch kann also das Ergebnis der vorigen sehen. Das gilt auch für Ergebnisse, die per a=k vom Handy kommen. Klickt die Beraterin am PC auf „In meinen Kalender eintragen“, landet die .ics-Datei mit der Frist der Klientin im Download-Ordner des Dienst-PCs. *Beleg:* demo.html:929-947 (zeigeErgebnis öffnet die Eingabe wieder, das Ergebnis bleibt stehen); keine Funktion zum Leeren oder Zurücksetzen (grep nach reload/zurücksetzen/leeren: nur Kartenreset beim nächsten Brief, demo.html:881); demo.html:1366-1373 (Ergebnis vom Handy wird ebenfalls nur angezeigt) *Vorschlag:* Unter dem Ergebnis einen Knopf „Fertig – vom Bildschirm löschen“ einbauen: Ergebnis ausblenden, letzteDaten leeren, Häkchen zurücksetzen (siehe DA2), nach oben scrollen. Bis dahin im Spickzettel und auf dem Handzettel den Tipp geben: „Nach jedem Gespräch die Seite neu laden. Am PC keinen Kalender-Eintrag, den macht die Klientin per ‚Ergebnis aufs Handy mitnehmen‘.“
+- **DA9 · Kleine Unstimmigkeiten zwischen Datenschutzerklärung und Code** (niedrig, stunden) — (a) In der Erklärung steht, die IP-Zähler würden „max. 30 Tage“ gespeichert. Im Code laufen sie nach 48 Stunden ab. Die Erklärung ist damit vorsichtiger als nötig, aber ungenau, und der Code-Kommentar redet noch von „30 Tagen“. (b) Der E-Mail-Hash wird ohne Ablaufzeit gespeichert, also dauerhaft, fehlt aber in Abschnitt 5 „Speicherdauer“. (c) Widerruf der Einwilligung über „Alle Daten löschen in den Einstellungen“ gibt es nur in der App, nicht auf der Webseite. (d) Als Datenschutz-Kontakt steht eine Gmail-Adresse. Ein Träger-DSB stört sich daran, weil Anfragen zu Klientendaten dann bei Google landen. (e) Die IP-Adressen stehen im Klartext in KV-Schlüsseln, und KV wird weltweit verteilt. Im Einrichtungs-Weg betrifft das nur falsche Code-Eingaben. *Beleg:* datenschutz.html:168 vs. proxy/src/index.ts:443 und 449-453 (TTL 48 h) sowie :73-77 (veralteter Kommentar); index.ts:456-457 (mailKey ohne TTL) vs. datenschutz.html:113-118; datenschutz.html:74-75; datenschutz.html:41 und 133; index.ts:356-357 und 723 (IP in Schlüsseln) *Vorschlag:* Speicherfristen in der Erklärung an den Code angleichen (48 Stunden), den E-Mail-Hash mit „dauerhaft, nur als Prüfsumme“ in Abschnitt 5 aufnehmen. Für die Webseite schreiben: „Widerruf jederzeit per E-Mail, wirkt für künftige Analysen.“ Als Kontakt eine Adresse @webklar.com oder @behoerdenklar.de verwenden, wie auf dem Handzettel. Optional die IP vor dem Speichern hashen.
+
+### Technik-Check des neuen Codes
+_Technisch ist der neue Code sauber gebaut. Verschlüsselung, Durable Object, Limits und Fehlerpfade sind durchdacht, nichts stürzt ab, und der geplante Vorführ-Ablauf (Arabisch am Laptop vorgewählt, ein Brief, eigenes Handy) funktioniert, soweit man ihn lokal testen kann. Flüssig ist es aber nur auf diesem Vorführ-Pfad: Bleibt der PC auf Deutsch eingestellt, kommt am PC kein Deutsch an. Ein zweiter Brief erscheint nicht am PC, und wenn das Handy neu lädt, ist die Verbindung still weg. Das größte Risiko für den 29.10.: Die zweisprachige Analyse und der ganze Handy-Ablauf sind noch nie echt gelaufen. Bis spätestens zum Wochenende muss deployt und mit einem echten Handy geprobt werden. (Pfade unten relativ zu /Users/homefolder/Behörden_App/beh-rde-brief)_
+
+- **TE1 · PC zeigt nur dann Deutsch, wenn am PC vorher eine Fremdsprache gewählt war** (hoch, minuten, vor Termin) — Im Beratungsalltag bleibt am PC meist 'Deutsch' eingestellt. Dann steht im QR-Code kein 'auch Deutsch' (d=1), und das Häkchen dafür ist sogar ausgeblendet. Wählt die ratsuchende Person am Handy ihre Sprache (z. B. Arabisch), wird nur auf Arabisch analysiert, und die Beraterin bekommt am PC Arabisch zu sehen. Damit klappt genau das nicht, was der Handzettel verspricht ('Sie lesen die Erklärung auf Deutsch, Ihr Gegenüber gleichzeitig in seiner Sprache'). In der Vorführung fällt es nicht auf, weil laut Ablaufplan am Laptop schon Arabisch gewählt ist. Im Testmonat trifft es aber die Beraterinnen. *Beleg:* webseite/demo.html:1297 (Häkchen bei 'de' versteckt), :1300 (d nur, wenn PC-Sprache nicht 'de'), :747 (Sprache kommt aus der Auswahl am Handy), :750 (auchDeutsch nur aus d); proxy/src/index.ts:281. Lokal beobachtet: PC auf Deutsch, in der Handy-Simulation auf Arabisch umgestellt, gesendet wurde {zielsprache:'ar'} OHNE auchDeutsch. Versprechen: marketing/praesentation-mbe/handzettel.html:127. *Vorschlag:* Die Richtung stimmt, nur 'immer true' würde ein bewusst abgewähltes Häkchen übergehen. Besser so: Das Häkchen am PC immer zeigen (Standard: an), in :1300 d='1' setzen, sobald es angehakt ist, egal welche Sprache am PC gewählt ist. Am Handy bleibt :750 dann unverändert. Der Worker ignoriert auchDeutsch bei 'de' sowieso (index.ts:281).
+- **TE2 · Zweisprachige Analyse ist nie gelaufen, und wenn die Übersetzung scheitert, merkt es niemand** (hoch, stunden, vor Termin) — Das Herzstück der Vorführung (PC Deutsch, Handy Arabisch, umschalten) wurde nie mit echtem KI-Schlüssel ausprobiert. Wenn die Haiku-Übersetzung scheitert, schickt der Worker still Deutsch zurück. Dann (a) zeigt das Handy ohne jeden Hinweis Deutsch, (b) zeigt der Umschalter zwei Knöpfe 'Deutsch | Deutsch', und (c) landet der Grund nur in console.log. Ohne [observability] in wrangler.toml kann man das später nicht nachlesen, nur live mit 'wrangler tail'. Außerdem laufen jetzt zwei KI-Aufrufe nacheinander (Sonnet, dann Haiku), die Wartezeit wird also länger. Die Seite verspricht 'bis zu einer Minute', bei Schriften wie Tigrinya kann die Übersetzung spürbar länger dauern (nicht gemessen). *Beleg:* proxy/src/index.ts:222-251 (jeder Fehler ergibt null), :479-484 (Rückfall: analyse_de = analyse, sprache 'de'); webseite/demo.html:857-861 (analyse_de wird immer als zweite Version angehängt). Lokal mit genau dieser Rückfall-Antwort nachgestellt: Der Umschalter zeigte ['Deutsch','Deutsch']. proxy/wrangler.toml hat keinen [observability]-Block. *Vorschlag:* 1) Gleich nach dem Deploy mit dem Musterbrief echt testen: Arabisch, Türkisch, Tigrinya, Zeit stoppen. 2) In bereiteVersionen die deutsche Version nur anhängen, wenn d.sprache !== 'de'. 3) Bei einem Rückfall im Worker z. B. 'uebersetzung_fehlgeschlagen: true' mitschicken und am Handy einen kurzen Satz zeigen ('Übersetzung hat nicht geklappt, hier auf Deutsch'). 4) In wrangler.toml '[observability] enabled = true' eintragen, dann sind Fehler im Cloudflare-Dashboard nachlesbar.
+- **TE3 · Den Handy-PC-Ablauf kann man lokal nicht echt testen: früh deployen und mit echtem Handy proben** (hoch, stunden, vor Termin) — Mit einem echten Handy lässt sich der neue Ablauf lokal nicht testen. Der QR-Code enthält 'http://localhost:4173/…', und das öffnet am Handy nichts. Öffnet man die Seite übers WLAN (http://192.168.…), gilt sie nicht als lokal: Sie spricht den LIVE-Worker an (der /uebergabe noch nicht kennt), nimmt den echten Turnstile-Schlüssel (an die Domain gebunden), und ohne HTTPS fehlt crypto.subtle. Der erste echte Test passiert also erst nach dem Deploy. Beim ersten Deploy kommen neu dazu: die Durable-Object-Migration und das [[ratelimits]]-Binding. SQLite-Durable-Objects laufen laut Cloudflare-Doku im kostenlosen Tarif. Ob das Rate-Limit-Binding im kostenlosen Tarif geht, sagen die Doku-Seiten nicht eindeutig. Die Reihenfolge ist wichtig: Geht die Webseite vor dem Worker live, laufen 'Code einlösen' und die QR-Übergabe ins Leere. npm run pruefung prüft die neuen Routen nicht. *Beleg:* webseite/uebergabe.js:15-16 (Live-Worker, außer bei localhost), :93 (QR-Adresse = aktuelle Seitenadresse); webseite/demo.html:354 (Test-Sitekey nur bei localhost), :540-542; proxy/wrangler.toml:24-38; tools/pruefung.js enthält keinen Test für /code oder /uebergabe. wrangler 4.110 ist installiert (für [[ratelimits]] ist mindestens 4.36 nötig). *Vorschlag:* Spätestens am Wochenende: erst den Worker deployen (cd proxy && npx wrangler deploy), dann die Webseite. Danach eine Generalprobe genau wie im Ablaufplan: Laptop und eigenes Handy über den Hotspot, einen TEST-Code mit dem Werkzeug anlegen (nicht den MBE-Code), Arabisch, ein Brief, 'Mitnehmen', 'Guthaben aufs Handy'. Scheitert der Deploy am Rate-Limit-Binding: den [[ratelimits]]-Block und index.ts:832-836 vorerst entfernen, die Grenze von 50 Schreibvorgängen pro Übergabe schützt weiter. In pruefung.js zwei Checks ergänzen: GET /uebergabe/<22 Zeichen> mit Origin ergibt 200 {faecher:{}}, OPTIONS /code ergibt 204.
+- **TE4 · Ein zweiter Brief vom Handy kommt am PC nicht mehr an** (hoch, minuten, vor Termin) — Nach dem ersten Ergebnis hört der PC auf zu warten und löscht die Übergabe. Das Handy bleibt aber im Modus 'verbunden', zeigt wieder den Hochlade-Knopf und weiter den Satz 'Die Erklärung erscheint hier und auf dem Bildschirm'. Fotografiert die Person einen zweiten Brief, sieht ihn nur das Handy, am PC passiert nichts. In der Beratung bringen Menschen oft mehrere Briefe mit. Gut möglich, dass eine Beraterin das schon bei der Vorführung ausprobieren will. *Beleg:* webseite/demo.html:1348-1352 (stoppeWarten + loeschen nach dem ersten Ergebnis), :812-816 (Handy öffnet die Eingabe wieder), :1417 (Banner-Text). Lokal nachgestellt: zwei verschlüsselte Ergebnisse nacheinander abgelegt, der PC zeigte weiter 'Kernaussage Brief 1'. *Vorschlag:* Schnell (Minuten): Nach dem ersten Ergebnis am Handy den Handy-Modus beenden und anzeigen: 'Für den nächsten Brief am Computer noch einmal auf „Lieber mit dem Handy fotografieren“ tippen.' Besser (später, Stunden): Der PC wartet weiter bis Ablauf oder Abbrechen, das Handy schickt eine laufende Nummer mit (ergebnis.nr), der PC zeigt jedes neue Ergebnis und löscht die Übergabe erst beim Abbrechen.
+- **TE5 · Lädt das Handy neu, ist die Verbindung zum PC weg, und die Seite springt still in den Gratis-/Kauf-Modus** (mittel, stunden, vor Termin) — Die Schlüssel stehen nur hinter dem # und werden direkt nach dem Öffnen aus der Adresse gelöscht (gewollt, wegen Datenschutz). Lädt die Seite am Handy neu, ist der Handy-Modus weg. Das passiert durch Herunterwischen, oder wenn ältere Android-Handys den Browser im Hintergrund beenden, während die Kamera-App offen ist. Dann fehlt das Banner, stattdessen erscheinen 'Guthaben kaufen' und der Code-Bereich. Analysiert die Person trotzdem, verbraucht sie ihre eigenen Gratis-Analysen (oder wird nach ihrer E-Mail gefragt), und der PC wartet bis zu 15 Minuten vergeblich. *Beleg:* webseite/demo.html:1507-1511 (Hash wird entfernt), :1412 (handyModus liegt nur im Arbeitsspeicher). Lokal beobachtet: Handy-Simulation neu geladen, danach Banner 'none', kaufBlock 'block', codeTeil 'block'. *Vorschlag:* Die Übergabe-Daten (s, k, w, d, l und die Startzeit) zusätzlich in sessionStorage merken (gilt nur für diesen Tab, wird beim Schließen gelöscht, mit try/catch absichern) und beim Laden ohne # wiederherstellen, solange die 15 Minuten nicht um sind.
+- **TE6 · Ein paar falsch getippte Codes sperren die ganze Beratungsstelle für den Tag** (mittel, minuten, vor Termin) — Pro IP-Adresse sind 10 falsche Codes am Tag erlaubt, danach wird JEDER Code abgelehnt, auch der richtige, denn die Sperre wird vor der Prüfung angewendet. In einer Beratungsstelle teilen sich alle PCs und meist auch das Gäste-WLAN eine öffentliche IP. Dazu kommt: 'MBEK7QX' ohne Bindestrich zählt als falsch, weil nur Leerzeichen entfernt werden. Umgekehrt schützt die Sperre schwächer gegen Raten, als der Kommentar behauptet: 4 Zufallszeichen aus 31 ergeben rund 920.000 Möglichkeiten, und mit IPv6 kann man die Adresse fast beliebig wechseln. Schlimmster Schaden: Das Test-Kontingent ist weg. *Beleg:* proxy/src/index.ts:719 (nur Leerzeichen raus, Großbuchstaben), :724-727 (Sperre vor der Prüfung), :732 (Fehlversuch zählen); tools/einrichtungs-code.js:82 (Code = PRÄFIX-4 Zeichen, mit Bindestrich). *Vorschlag:* Vergleichen ohne Bindestriche: im Worker code.replace(/[^A-Z0-9]/g, '') und den Bindestrich nach dem Präfix wieder einsetzen. Alternativ die Codes ohne Bindestrich speichern und beim Einlösen alles außer Buchstaben und Ziffern entfernen. Die Grenze auf etwa 30 anheben. Die restlichen Punkte passen so.
+- **TE7 · Verbietet der Browser das Speichern, reagiert die Demo-Seite gar nicht mehr** (niedrig, minuten, vor Termin) — Mehrere Funktionen greifen ohne try/catch auf localStorage zu. In Browsern, die Website-Daten blockieren (Safari mit 'Alle Cookies blockieren', Firefox mit gesperrten Cookies, manche App-internen Browser), wirft schon der Zugriff einen Fehler. Folge: Das Startskript bricht ab (Handy-Knopf erscheint nicht, ein gescannter QR wird nicht ausgewertet), und 'Brief auswählen' öffnet keine Dateiauswahl. Die Person sieht einfach nichts passieren. Die Sprachwahl ist schon abgesichert, der Rest nicht. Der normale private Modus im aktuellen Safari ist nicht betroffen. *Beleg:* webseite/demo.html:594-605 und :629-630 ohne try/catch (zum Vergleich :565-566 mit try/catch). Abbruch beim Start in :1513 (zeigeStand), deshalb laufen :1514-1516 nicht mehr. Lokal nachgestellt: localStorage zum Werfen gebracht, Häkchen gesetzt, 'Brief auswählen' geklickt, Ergebnis 'Uncaught SecurityError', Dateiauswahl nicht geöffnet. *Vorschlag:* Eine kleine Hilfsfunktion 'speicher' mit get/set/remove in try/catch, die bei Fehler ein Objekt im Arbeitsspeicher nimmt. Alle localStorage-Aufrufe darüber laufen lassen. Außerdem sollte zielsprache() den aktuellen Wert der Auswahlliste nehmen, nicht nur localStorage.
+- **TE8 · Der Guthaben-Zähler kann sich verzählen, und für die Auswertung gibt es keine anderen Zahlen** (mittel, minuten, vor Termin) — Das Abziehen läuft so: lesen, KI fragen (30-90 s), dann Wert minus 1 schreiben. Laufen zwei Analysen über denselben Einrichtungs-Code gleichzeitig (mehrere Beraterinnen, oder Ratsuchende zuhause), lesen beide z. B. 57 und schreiben beide 56, eine Analyse wird also nicht gezählt. KV ist außerdem nicht sofort überall aktuell. Auch das Aufladen mit dem Werkzeug kann eine gerade laufende Analyse überschreiben. Bei gekauftem Guthaben ist das eine Lücke: viele gleichzeitige Anfragen ergeben viele Analysen für 1 Credit. Für den Auswertungstermin in 4 Wochen ist der Restzähler die einzige Zahl. Es gibt kein Protokoll, wie viele Briefe an welchen Tagen in welchen Sprachen erklärt wurden. *Beleg:* proxy/src/index.ts:318-322 (lesen), :395-419 (KI-Aufruf dazwischen), :446 (walletRest - 1 schreiben); tools/einrichtungs-code.js:93-96 (aufladen = lesen + schreiben). Cloudflare-KV-Doku: Änderungen erst 'bis zu 60 Sekunden oder mehr' später an anderen Standorten sichtbar, keine atomaren Operationen. *Vorschlag:* Vor dem 29.10. (Minuten): pro Analyse über einen Einrichtungs-Code einen eigenen KV-Schlüssel schreiben, z. B. 'nutzung:<walletId>:<datum>:<zufall>' mit der Sprache als Wert. Jeder Schlüssel ist eindeutig, also kein Verzählen. Zählen mit 'wrangler kv key list --prefix nutzung:<walletId>'. Workers-Logs eignen sich dafür nicht, sie werden nur wenige Tage aufbewahrt. Später (Stunden): Guthaben pro Wallet in einem Durable Object führen (atomar, wie bei der Übergabe), vor dem KI-Aufruf reservieren und bei Fehler zurückbuchen.
+- **TE9 · 'Ergebnis aufs Handy mitnehmen': Auf einem fremden Handy fehlt die Übersetzung der Anruf-Sätze** (mittel, minuten, vor Termin) — Ob unter jedem deutschen Telefon-Satz die Übersetzung steht, hängt an der Sprache, die im Browser des Handys gespeichert ist, nicht an der Sprache des Ergebnisses. Der Mitnehmen-QR enthält keine Sprache. Auf dem Handy einer ratsuchenden Person, die die Seite noch nie offen hatte, ist 'de' gespeichert, also werden z. B. die arabischen Bedeutungen der Anruf-Sätze ausgeblendet. In der Vorführung fällt das nicht auf, weil Justins Handy vorher per QR auf Arabisch gestellt wurde. *Beleg:* webseite/demo.html:1133 (mitBedeutung = zielsprache() !== 'de'), :1383 (Mitnehmen-QR nur mit a, s, k), :563-568 (zielsprache aus URL oder localStorage). *Vorschlag:* zeigeAnruf die Sprache der gerade angezeigten Version mitgeben (versionen[aktiveVersion].code) und mitBedeutung = code !== 'de' setzen. Alternativ l=<sprache> in den Mitnehmen-QR schreiben.
+- **TE10 · Nach einem Fehler dieselbe Datei nochmal wählen: Es passiert nichts** (niedrig, minuten, vor Termin) — Das Datei-Feld wird nie geleert, und Browser melden eine Dateiauswahl nur, wenn sie sich ändert. Wer nach 'KI ausgelastet, bitte erneut versuchen' denselben Scan oder dasselbe PDF wieder auswählt (typisch am Beratungs-PC), sieht keine Reaktion. Mit der Handy-Kamera passiert das nicht, weil jedes Foto eine neue Datei ist. *Beleg:* webseite/demo.html:678-680 (nur das change-Ereignis startet die Analyse). Die Datei enthält nirgends 'dateiFeld.value = ""'. Fehlerpfade danach: :760-799 und :828-833. *Vorschlag:* In starteAnalyse direkt am Anfang (nachdem die Datei übergeben wurde) dateiFeld.value = '' setzen.
+- **TE11 · Werkzeug einrichtungs-code.js: Ein Tippfehler kann unbegrenztes Guthaben erzeugen** (niedrig, minuten, vor Termin) — '--briefe' ohne gültige Zahl ergibt NaN. Der Worker prüft nur 'walletRest <= 0', und 'NaN <= 0' ist falsch, also hätte der Code unbegrenzt viele Analysen. '--bis' wird nicht geprüft: '31.12.2026' wird als Text mit '2026-10-29' verglichen und läuft praktisch nie ab. Ist der wrangler-Login abgelaufen, meldet 'stand' fälschlich 'Code gibt es nicht', weil jeder Lesefehler als 'nicht vorhanden' gilt. Relevant, weil Justin den MBE-Code vor dem Termin mit diesem Werkzeug anlegt. *Beleg:* tools/einrichtungs-code.js:80-81 (keine Prüfung von --briefe/--bis), :29-31 (jeder Fehler wird zu null); proxy/src/index.ts:322 + :327 (NaN kommt durch), :324 (Datum als Text verglichen). *Vorschlag:* Im Werkzeug abbrechen, wenn briefe keine Zahl größer 0 ist oder bis nicht im Format JJJJ-MM-TT vorliegt. Im Worker 'if (!(walletRest > 0))' statt 'if (walletRest <= 0)'. Beim Lesen nur bei 'nicht gefunden' null zurückgeben, sonst den Fehler anzeigen. Nach dem Anlegen einmal 'stand' ausführen und die Werte prüfen.
+
+### Angebot und Betrieb nach dem Termin
+_Das Angebot ist für eine MBE einladend und ohne Risiko: kostenlos, kein Vertrag, Ratsuchende zahlen nichts, ein Code für alle, und der Datenschutz ist ehrlich erklärt. Der Alltag nach dem Termin ist aber noch nicht bequem genug. Es gibt nichts, was den Code zu den Ratsuchenden bringt (kein Aushang, keine Karte, nichts in ihren Sprachen). Das Testende ist so eingestellt, dass der Zugang ungefähr am Auswertungstag ausläuft, und niemand bekommt vorher eine Erinnerung. Die Beratungsstelle sieht ihren Verbrauch kaum. Für die Zeit nach dem Test fehlen ein schriftliches Angebot und eine Rechnung, wie Träger sie brauchen. Dazu kommt ein echter Fehler: Wer die 2 Gratis-Analysen schon verbraucht hat, sieht das Code-Feld gar nicht mehr. Fast alles davon ist mit wenigen Stunden Arbeit bis zum 29.10. lösbar._
+
+- **AN1 · Wer die 2 Gratis-Analysen schon verbraucht hat, sieht das Code-Feld nicht mehr** (hoch, minuten, vor Termin) — Das Feld 'Sie haben einen Code von einer Beratungsstelle?' liegt innerhalb des Eingabebereichs. Wenn in einem Browser schon 2 Gratis-Analysen gemacht wurden, blendet die Seite diesen ganzen Bereich aus. Dann bleiben nur noch die Kauf-Knöpfe (2,99 €/6,99 €) und die Warteliste. Das Code-Feld ist nicht mehr zu finden. Das trifft genau die Richtigen: Beraterinnen, die den Link aus Justins Mails (outreach-september.md:50) am Büro-PC schon ausprobiert haben, und Ratsuchende, die BehördenKlar schon kennen. Sie können den Code vom Zettel nicht eintippen und landen beim Bezahlen. Nur der QR-Code oder der vollständige Link funktioniert dann noch. *Beleg:* demo.html:287 (div#eingabe) umschließt demo.html:372-377 (details#codeTeil). demo.html:658-661 setzt bei benutzt()>=2 eingabe.style.display='none'. Lokal im Browser geprüft (bk_demo_v2=2): #eingabe display:none, Code-Feld unsichtbar. Sichtbar sind nur noch '5 Analysen 2,99 €', '15 Analysen 6,99 €', Kauf-Häkchen und Warteliste. *Vorschlag:* Der Vorschlag passt (details#codeTeil hinter #eingabe setzen; zeigeStand steuert es schon selbst). Danach zwei Fälle testen: localStorage bk_demo_v2=2 und eine Antwort 'aufgebraucht' vom Worker. Darauf achten, dass das Feld nicht beim Laden der Analyse und nicht im Mitnehmen-Modus (a=m) am Handy unter dem Ergebnis auftaucht. Gegebenenfalls in starteAnalyse und pruefeUebergabe auch codeTeil ausblenden.
+- **AN2 · Der Test endet ungefähr am Auswertungstag, und niemand bekommt eine Erinnerung** (mittel, minuten, vor Termin) — '--monate 1' rechnet einen Monat ab dem Tag, an dem der Code angelegt wird. Wird er wie geplant am Vorabend (28.10.) angelegt, gilt er bis 28.11., also nur 2 Tage nach der Auswertung am 26.11. Wird er schon jetzt für den Druck angelegt (22.10.), endet er am 22.11., also VOR der Auswertung. Sagt die MBE am 26.11. 'Ja', laufen Angebot, Bestellung und Rechnung beim Träger länger als 2 Tage. In dieser Lücke bekommen Ratsuchende 'abgelaufen. Bitte fragen Sie dort nach.' Danach wird ihr Zugang gelöscht und die Seite bietet ihnen den Kauf für 2,99 € an. Das widerspricht dem Versprechen 'Ratsuchende zahlen nichts'. Außerdem ist 1 Monat für eine kleine MBE knapp: Die erste Woche geht für Team-Info und Aushang drauf, und viele Ratsuchende kommen erst Wochen später wieder. Bis zur Auswertung gibt es also wenig Erfahrung mit der Nutzung zu Hause. Weder die MBE noch Justin wird an das Testende erinnert, und auf dem Handzettel steht kein Datum. *Beleg:* einrichtungs-code.js:46-50 und :81 (Ablauf = heute + 1 Monat). proxy/src/index.ts:324-326 und :735-736 (nach dem Ablaufdatum gesperrt). demo.html:783-789 (Zugang wird gelöscht, zeigeStand zeigt den Kaufbereich, demo.html:655). ablaufplan.html:88 (Auswertung 26.11.) und :114 (Code am Vorabend). handzettel.html:170 ('1 Monat', kein Datum). *Vorschlag:* Code mit festem Datum anlegen, das deutlich nach der Auswertung liegt, z. B. --bis 2026-12-18 oder 2026-12-31. Dann aber auch Handzettel (handzettel.html:170 '1 Monat') und den Satz im Ablaufplan (Zeile 87 'einen Monat') anpassen, z. B. 'Test bis 18.12., nach 4 Wochen schauen wir gemeinsam'. Sonst widersprechen sich Zettel und Code. Kalender-Erinnerung 7 Tage vor Ablauf. Bei Zusage sofort 'verlaengern', also bevor der Zugang abläuft und die Seiten der Ratsuchenden den Zugang löschen.
+- **AN3 · Nichts bringt den Code zu den Ratsuchenden (kein Aushang, keine Karte, nichts in ihren Sprachen)** (mittel, stunden, vor Termin) — Der Handzettel ist für Beraterinnen gemacht: deutsch, dichter Text in 9 pt, A4, 5 Stück. Der Code steht nur in einem kleinen Kasten 'Code für Ihre Ratsuchenden'. Ratsuchende bekommen also nur etwas, wenn die Beraterin jedem einzeln das A4-Blatt hinhält oder den Code diktiert. Dann bleibt das Versprechen in der Überschrift ('verstehen den Brief, bevor sie zu Ihnen kommen') leer, denn zu Hause hat niemand den Code. Für Beraterinnen ist das zusätzliche Arbeit in jedem Termin, und das ist erfahrungsgemäß der häufigste Grund, warum ein Test einschläft. Die Seite hinter dem QR-Code ist außerdem ganz deutsch ('Gratis-Demo', '2 Gratis-Analysen', Einverständnis-Häkchen). Wer kein Deutsch liest, weiß nicht, dass er zuerst das Häkchen setzen muss. *Beleg:* handzettel.html:93-99 (richtet sich an die Beratungsstelle), :172-175 (der einzige QR mit Code). demo.html:2 lang=de, :284 'Antrag auf Klartext · 2 Gratis-Analysen' (bleibt auch mit Code so), :305-315 Einverständnis auf Deutsch. Lokal geprüft: /demo.html?code=…&sprache=ar stellt die Sprache auf Arabisch, die Bedienung bleibt deutsch. *Vorschlag:* Vor dem 29.10. reicht eine einfache Version: ein A5-Aushang und A7-Karten mit großem QR (Code schon im Link), 'kostenlos' und 3 Symbol-Schritte (Häkchen, Foto, Sprache). Text auf Deutsch, höchstens mit 1-2 Sätzen in den Hauptsprachen der MBE. Mehrsprachige Texte und eigene QRs pro Sprache besser NACH dem Termin gemeinsam mit den Beraterinnen machen: Sie wissen, welche Sprachen gebraucht werden, und können gegenlesen. Ungeprüfte KI-Übersetzungen (z. B. Tigrinya, Paschtu, siehe FEATURES.md) nicht ungeprüft drucken.
+- **AN4 · Die Beratungsstelle sieht kaum, wie viel verbraucht ist, und für die Auswertung gibt es nur eine einzige Zahl** (niedrig, stunden) — Die Datenschutzerklärung verspricht, dass die Beratungsstelle sieht, 'wie viele Analysen noch übrig sind'. Das geht aber nur über die Zahl im Banner im eigenen Browser. Diese Zahl ist im Browser gespeichert und wird nur aktualisiert, wenn dieser Browser selbst etwas tut. Briefe, die Ratsuchende zu Hause machen, sieht die Beraterin nicht. Ein Ablaufdatum wird nirgends angezeigt, obwohl der Worker es beim Einlösen mitschickt. Für die MBE heißt das: Sie muss Justin anrufen. Justin selbst bekommt mit 'stand' nur 'Übrig: X Briefe'. Bei der Auswertung am 26.11. kann er also nur sagen: '23 Briefe verbraucht'. Er weiß nicht, wann (abends oder in der Beratung), in welchen Sprachen und ob sie von MBE-Ratsuchenden kamen. Dabei sind genau diese Zahlen das stärkste Argument für das Bezahlen. *Beleg:* datenschutz.html:224-225 (Versprechen). demo.html:620-623 und :643-645 (Banner liest den gespeicherten Wert). proxy/src/index.ts:742 schickt 'ablauf' mit, in demo.html kommt 'ablauf' kein einziges Mal vor (grep). einrichtungs-code.js:61-69 (zeigt nur Übrig und Gültig bis). index.ts:446 (es wird nur heruntergezählt). *Vorschlag:* Nur die kostenlosen Teile übernehmen: wöchentliche Stand-Mail aus 'stand' und den Beraterinnen sagen 'Link vom Zettel neu öffnen, dann stimmt die Zahl'. Für die Auswertung reicht eine kurze Strichliste oder 3 Fragen. 'gültig bis' im Banner anzeigen ist ein kleiner Gewinn für später. Zusätzliche Zählung nach Sprache und Zeit erst dann, wenn die Datenschutzerklärung angepasst ist.
+- **AN5 · Kein Angebot und keine Rechnungsvorlage für die Zeit nach dem Test, und die Pakete sind für Träger zu kleinteilig** (mittel, stunden) — Die Preise gibt es nur intern, 'nur im Gespräch' (100 Briefe 20 €, 500 Briefe 75 €). Auf dem Handzettel steht nur 'festes Briefkontingent zu einem Preis für Beratungsstellen'. Ein Träger kann ohne schriftliches Angebot nichts bestellen und ohne ordentliche Rechnung nichts per Überweisung bezahlen. Im Repo gibt es weder Angebot noch Rechnung, und die AGB gelten nur für Verbraucher, die mit Stripe kaufen. Kleine 20-€-Pakete bedeuten außerdem: Jedes Mal, wenn sie leer sind, braucht es einen Anruf, eine neue Rechnung und eine neue Zahlungsanweisung. Der Verwaltungsaufwand ist dann größer als der Betrag. Die interne Notiz 'Den Einrichtungs-Code gibt es technisch noch nicht' ist außerdem veraltet. *Beleg:* outreach-september.md:314-335 (Preisblatt, Zeile 334 veraltet). handzettel.html:161-164 (keine Zahl). grep nach Rechnung/Angebot/IBAN in marketing/ und rechtliches/: nur Treffer im Musterbrief. agb.html:44-45 (Verbraucher). FEATURES.md: Kleinunternehmer § 19. *Vorschlag:* Bis zum 26.11. ein einseitiges Angebot vorbereiten (Leistung, Briefzahl, Laufzeit, Endpreis mit Hinweis auf § 19 UStG, Zahlung auf Rechnung). Für die Rechnung die vorhandene Webklar-Vorlage nehmen, falls es eine gibt. Ein Jahreskontingent mit fester Briefzahl und einer Rechnung pro Jahr ist sinnvoll ('Jahreslizenz mit X Briefen' steht schon in outreach-september.md). Nachladen aber nur gegen neue Rechnung im Voraus, damit die eigene Regel 'erst bezahlt, dann genutzt' gilt. Die veraltete Zeile 334 korrigieren.
+- **AN6 · Das Datenschutz-Blatt für Beratungsstellen ist veraltet und sagt etwas Falsches über die Webseite** (mittel, stunden, vor Termin) — Bevor ein Träger einen Test erlaubt, fragt erfahrungsgemäß die Leitung oder die Datenschutzbeauftragte nach einer Unterlage. Die einzige Unterlage dafür ist vom 15.07. Darin stehen '9 weitere Sprachen', die alte Domain behoerdenklar.pages.dev und eine Gmail-Adresse. Vor allem steht dort: 'die Briefe ... liegen verschlüsselt auf deren eigenem Handy, nicht bei uns'. Das stimmt nur für die App. Im eigenen Ablaufplan steht genau das unter 'Nicht sagen'. Einrichtungs-Code und PC-Handy-Übergabe kommen im Blatt gar nicht vor. Schickt Justin dieses Blatt nach dem Termin, widerspricht es dem Handzettel und kann den Teststart verzögern. *Beleg:* rechtliches/datenschutz-factsheet.md Zeile 4 (Stand 15.07., pages.dev), Zeile 9 ('9 weiteren Sprachen'), Zeilen 17-19 ('liegen verschlüsselt auf deren eigenem Handy'). ablaufplan.html:147 ('Alles bleibt auf dem Handy: Das stimmt für die Webseite nicht'). Aktuelle Fassung in datenschutz.html:218-228 (9a/9b). *Vorschlag:* Der Vorschlag passt. Ergänzung: Im Termin kurz sagen 'Das Datenschutz-Blatt aus dem Juli beschrieb die App. Für die Webseite gilt dieses neue Blatt.' Wenn die Zeit vor dem 29.10. knapp ist, reicht auch ein Ausdruck der aktuellen datenschutz.html (Abschnitte zur Demo, 9a und 9b) als Übergangslösung. Das alte factsheet/PDF als veraltet markieren, damit es nicht noch einmal verschickt wird.
+- **AN7 · Ein Leerzeichen statt Bindestrich zählt als falscher Code, und 10 Fehler sperren das ganze Büro für den Tag** (mittel, minuten, vor Termin) — Der Worker entfernt nur Leerzeichen. Wer 'MBE K7QX' oder 'MBEK7QX' tippt, bekommt 'Diesen Code kennen wir nicht', und das zählt als Fehlversuch. Nach 10 Fehlversuchen pro IP-Adresse und Tag ist Schluss. Die Sperre wird geprüft, BEVOR der Code geprüft wird, also wird dann auch der richtige Code abgelehnt ('Bitte versuchen Sie es morgen wieder'). In einer Beratungsstelle teilen sich alle Büro-PCs und oft auch das WLAN für Gäste eine IP-Adresse. Ein paar Tippfehler von Ratsuchenden reichen, und an diesem Tag kann im ganzen Haus niemand mehr einen Code einlösen. *Beleg:* proxy/src/index.ts:719 (.replace(/\s+/g,'') entfernt nur Leerzeichen, fügt keinen Bindestrich ein), :688 (CODE_FEHLVERSUCHE_PRO_TAG = 10), :723-727 (die Sperre kommt vor der Code-Prüfung), :731-733 (jeder unbekannte Code wird gezählt). demo.html:1235 (die Seite macht nur Großbuchstaben). Lokal per curl getestet: unbekannter Code ergibt code_unbekannt. *Vorschlag:* Im Worker alles außer A-Z und 0-9 entfernen und den Bindestrich vor den letzten 4 Zeichen selbst einsetzen. Dann gehen 'mbe k7qx', 'MBEK7QX' und 'MBE-K7QX'. Die Grenze auf etwa 30 pro Tag anheben: Bei 31^4 möglichen Codes pro Präfix bleibt Raten trotzdem aussichtslos. Das geht in den Deploy, der vor dem 29.10. sowieso ansteht.
+- **AN8 · Den Test im Termin starten, nicht danach, und den Weg 'Zugang aufs Handy' zeigen** (mittel, minuten, vor Termin) — Im Ablaufplan endet das Angebot damit, dass der Handzettel übergeben wird ('Der Code steht hier auf dem Zettel'). Danach muss die MBE selbst anfangen: Code einlösen, Kolleginnen informieren, Ratsuchenden erklären. Erfahrungsgemäß bleibt das im Alltag liegen. Der bequemste Weg im Alltag kommt weder in der Vorführung noch auf dem Handzettel vor: Am Beratungs-PC auf '📱 Auch auf dem Handy nutzen' klicken. Die Ratsuchende scannt den QR-Code und kann danach zu Hause selbst Briefe erklären lassen, ohne Zettel und ohne Tippen. Gezeigt wird nur 'Ergebnis mitnehmen'. *Beleg:* ablaufplan.html:85-88 (Übergabe nur auf Papier), :70-76 (Vorführung ohne a=g). handzettel.html:125-132 (nur 'Beratung am PC' und 'Ergebnis zum Mitnehmen'). demo.html:294 und :1392-1397 (Knopf 'Auch auf dem Handy nutzen' gibt Zugang und Name der Stelle weiter, Art a=g). demo.html:1457 ('Übernommen. BehördenKlar ist für Sie kostenlos, über …'). *Vorschlag:* Der Vorschlag passt, mit einer Änderung: Für den Schritt 'Auch auf dem Handy nutzen' vorher den MBE-Code am Laptop einlösen (Handzettel-QR oder ?code=), sonst geht der Vorführ-Zugang weiter. Alternativ den Knopf nur zeigen und erklären, aber nicht scannen lassen. Die Zeile auf dem Handzettel ergänzen.
+- **AN9 · Ohne eingetragenen Code führt der QR auf dem Handzettel zur Kaufseite** (niedrig, minuten, vor Termin) — Das vorhandene handzettel.pdf/png wurde ohne Code erzeugt: Dort steht 'wird beim Termin eingetragen', und der QR zeigt nur auf behoerdenklar.de/demo. Druckt Justin diese Fassung oder trägt den Code nur von Hand ein, landen alle, die den QR scannen (also der bequemste Weg), in der normalen Gratis-Demo. Nach 2 Briefen kommt dort der Kauf für 2,99 €. Nur wer den Code von Hand eintippt, nutzt den Zugang der MBE. Das ist das Gegenteil von 'Ratsuchende zahlen nichts'. *Beleg:* handzettel.html:190-191 (CODE='' ergibt QR auf https://behoerdenklar.de/demo), :197 (Platzhaltertext). handzettel.png angesehen: Platzhalter 'wird beim Termin eingetragen', Link 'behoerdenklar.de/demo'. Der Haken 'MBE-Code angelegt, im Handzettel eingetragen' steht in ablaufplan.html:114. *Vorschlag:* Die Checkliste in ablaufplan.html:113-115 um 2 Punkte ergänzen: 'gedruckten QR mit dem Handy getestet, es erscheint Kostenlos über MBE Donnersberg' und 'alte handzettel.pdf/png ohne Code nicht mehr verwenden'. Den Rest gibt es schon.