docs: Wackeltest-Befund in STATE.md nachgezogen (quick-260921-ldf)

Der rote CI-Lauf 395 war kein Zufall und kein Testproblem: der
Fehler-melden-Dialog stand bei jedem Oeffnen kurz mit ausgeschaltetem
Haekchen da, weil er dauerhaft eingehaengt war und sein Anfangswert nur
einmal lief. Deterministisch belegt ueber jeden DOM-Commit, im
Produktcode behoben.

Die 20 gruenen Stabilitaetslaeufe gelten ausdruecklich nicht als Beweis
- bei Ausgangsrate 1:17 waeren sie auch ohne Reparatur zu rund 30
Prozent zu erwarten.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J

.planning/STATE.md

@@ -4,8 +4,8 @@ milestone: v1.2
 current_phase: 18
 current_phase_name: desktop-client-fertigstellen
 status: verified
-stopped_at: "Acht Quick-Vorgaenge am 2026-09-21 (9ie, a1d, bi2, fi3, gof, i8x, iwr, jt4). OFFEN UND WICHTIG: CI-Lauf 395 war rot wegen eines WACKELTESTS, nicht wegen der Arbeit — apps/web/src/components/bug-report/bug-report-button.test.tsx Test 1 faellt rund einmal in 17 vollen Laeufen durch (Vorschaubild da, Haekchen 'Bildschirmfoto anhaengen' aus). Stammt aus quick-260914-m97. Noch NICHT geklaert, ob das nur im Test so aussieht oder ob ein Nutzer sein Bild in der Vorschau sieht und es trotzdem nicht mitgeschickt wird — das ist der naechste Auftrag. Danach: 288 any in apps/api, dann zwei neue Dashboard-Widgets (eins davon ein Bilderrahmen, das zweite noch unbenannt). jt4 ist noch nicht gepusht."
-last_updated: "2026-09-21T13:30:00.000Z"
+stopped_at: "Neun Quick-Vorgaenge am 2026-09-21 (9ie, a1d, bi2, fi3, gof, i8x, iwr, jt4, ldf). Der Wackeltest aus CI-Lauf 395 ist geklaert und war ein Produktfehler. Offen: 288 any in apps/api (reine Typarbeit), danach zwei neue Dashboard-Widgets. Das erste ist ein Bilderrahmen: Bilder werden hochgeladen ODER per https-Webadresse eingebunden (Browser laedt direkt, kein Server-Abruf, damit keine SSRF-Flaeche); Einstellungen fuer Bildausschnitt, Wechselintervall, Reihenfolge/Zufall, Bildunterschrift, Klick zeigt gross. Das zweite Widget hat der Nutzer noch nicht benannt. ldf ist noch nicht gepusht."
+last_updated: "2026-09-21T14:15:00.000Z"
 last_activity: 2026-09-21
 last_activity_desc: Quick 260921-9ie, a1d, bi2, fi3 und gof — Lint-Tor scharf, Benutzerverwaltung meldet abgewiesene Aktionen, Lint-Rueckstand 2923 → 446, erzwungener Passwortwechsel an der API durchgesetzt (war eine tote Sperre), 21 Effekt-Abhaengigkeiten einzeln beurteilt; alle fuenf verifiziert, die letzten drei am laufenden System
 state_head: 4d485432c003a6caf68f6d85aff7de0bd27794e2
@@ -31,7 +31,7 @@ See: .planning/PROJECT.md (updated 2026-07-17)
 Phase: 18 (desktop-client-fertigstellen) — COMPLETE (2026-09-17, Verifikation passed, Windows-Bedienprobe bestanden)
 Plan: 6 of 6
 Status: Alle 18 Phasen abgeschlossen; Version 1.2.0 freigegeben. Kein laufender Meilenstein. Nach 1.2.0 auf main (Beta): Bildmarke in Akzentfarbe, CI-Desktop-Skip, Favoriten-Symbol/-Sortierung, Desktop-Server-Adresse, Update in der App (signiert), Versionszeile auf der Setup-Seite — alles verifiziert und auf VM/CI nachgewiesen
-Last activity: 2026-09-21 - Quick 260921-jt4: Barrierefreiheit 30 → 1 Befund und die vier Restposten erledigt; zwei Vorgaben des Orchestrators vom Planer widerlegt (Rueckfallweg erzeugt neue Befunde, vier vermeintliche Klicks sind onError-Handler). Kalender-Verschwendung im Browser nachgemessen, 5-Minuten-Auffrischer per gestellter Uhr als intakt belegt
+Last activity: 2026-09-21 - Quick 260921-ldf: der Wackeltest aus CI-Lauf 395 war ein echter Produktfehler — der Fehler-melden-Dialog stand bei jedem Oeffnen kurz mit ausgeschaltetem Haekchen da; Ursache behoben, nicht der Test beruhigt
 
 Progress: [██████████] 99%
 
@@ -452,6 +452,7 @@ Gerettet aus `.continue-here.md`. Relevant fuer die noch offenen Live-Tests.
 | 260921-i8x | **Fuenf fehlerverdaechtige Lint-Klassen geprueft — kein einziger echter Fehler darunter.** Zwoelf Stellen einzeln beurteilt, Ergebnis: 7x gleichwertig oder Absicht, 2x Haertung, 3x idiomatisch korrekt. Das ist das Ergebnis, keine Ausrede — die Klassen klangen gefaehrlicher als sie waren. **Die eine Stelle mit echtem Wert:** `apps/web/src/lib/safe-next.ts`, der Schutz gegen Weiterleitung auf fremde Seiten nach der Anmeldung. Der Kommentar dort behauptete, die Steuerzeichen stuenden als Unicode-Escapes im Muster; die rohen Bytes zeigten das Gegenteil (NUL, 0x1F, 0x7F direkt eingebettet). Funktionierte, war aber zerbrechlich: verschluckt ein Werkzeug das NUL-Byte, wird aus dem Bereich stillschweigend ein anderer und der Schutz loechrig — der Rueckgabewert landet in `login/page.tsx` direkt in `window.location.href`. Jetzt echte Escapes, Datei ohne ein einziges Steuerbyte. **Beweis der Gleichwertigkeit, nicht Behauptung:** ueber alle 65536 Codepunkte dieselbe Menge abgelehnter Zeichen — 54 Stueck (32 Steuerzeichen 0x00-0x1F, dazu 0x7F, Backslash und die 20 Leerraum-Zeichen von `\s`), null Abweichung; vom Orchestrator unabhaengig gegen ein selbst gebautes Referenzmuster nachgerechnet. **Bewusst nicht angefasst:** die NUL-Maskierung in `ldap.service.ts` (RFC 4515) — genau dieses Zeichen zu treffen ist ihr Zweck, wer sie "repariert", oeffnet LDAP-Filter-Injection. Ebenso die drei `while ((m = re.exec(s)))`-Schleifen (idiomatisch, kein verrutschtes Gleichheitszeichen) und `noUselessSwitchCase` aus bi2. **Zwei Korrekturen an frueheren Annahmen:** `sanitizeNextPath` laeuft NICHT in der Edge-Middleware (die importiert nur `buildNextParam`), und das blosse Umschreiben auf Escapes senkt die Warnzahl nicht — Biome beanstandet die Escape-Schreibweise genauso, es braucht zusaetzlich einen einzeiligen Unterdrueckungskommentar. **Werkzeugfalle, dreimal zugeschnappt:** das Schreibwerkzeug wandelt `\uXXXX` still in das echte Zeichen um — der Planer erzeugte so zehn rohe Steuerbytes in seiner ersten Planfassung, der Executor zweimal in Commit-Text und Akte (git verweigerte den Commit wegen eines NUL-Bytes), und der Orchestrator beim Nachrechnen. Umgehung ueber `python3`/`chr(92)` ist im Plan hinterlegt. **Zahlen:** 446 → 434, `noControlCharactersInRegex`/`useIterableCallbackReturn`/`noGlobalIsNan` je 0, `suppressions/unused` 0, web-Tests 67/477 → 68/481, api 71/1136 → 72/1137, type-check 4/4, lint 5/5. | 2026-09-21 | f85c91b,076ca4b,b92dd5d | [260921-i8x-fehlerverdaechtige-lint-klassen-steuerze](./quick/260921-i8x-fehlerverdaechtige-lint-klassen-steuerze/) |
 | 260921-iwr | **Listenschluessel und Ausrufezeichen-Zusicherungen: 30 Stellen geprueft, wieder kein echter Fehler.** Damit ist der fehlerverdaechtige Rueckstand abgearbeitet. **Zwei Vorannahmen des Orchestrators widerlegt, beide durch Messung statt Argument:** (1) Die LDAP-Seite galt als heisser Kandidat, weil dort Zuordnungsregeln hinzugefuegt und geloescht werden — die Liste, die tatsaechlich waechst und schrumpft (`config.fieldMappings`), benutzt jedoch laengst `key={mapping.id}`; die sechs Meldungen betreffen zustandslose Textlisten. (2) Im Cert-Manager galt eine Zusicherung auf hochgeladenen Dateiinhalt als moeglicher Absturz — der Planer hat eine 83-Byte-Schrottdatei gebaut, die node-forge `bag.cert = null` setzen laesst, und gegen den echten Dienst laufen lassen: **alle vier Pfade enden mit 400, nie 500**, und `certificateToPem(null)` wirft nachweislich, statt still ein falsches Zertifikat zu bauen. Also weder Verfuegbarkeits- noch Integritaetsluecke, sondern eine irrefuehrende Fehlermeldung. **Ein Fund dreht die Richtung um:** bei `admin/modules/grants/page.tsx:246` waere die Korrektur schaedlich — die Gruppierung fasst nur aufeinanderfolgende Kategorien zusammen, die Positionsnummer ist dort fuer die Eindeutigkeit noetig, ohne sie entstuenden doppelte Schluessel. **Geaendert: 5 Stellen** (drei Waechter im Cert-Manager, die den Meldungstext praezisieren — Status bleibt 400, rot-dann-gruen belegt; zwei ueberfluessige Zusicherungen in `imap.provider.ts`, die imapflow ohnehin als Pflichtfeld typisiert). **25 Stellen bleiben bewusst stehen und bleiben in der Zaehlung sichtbar** — mit Begruendung je Stelle in der Akte, damit der naechste Durchgang sie nicht erneut aufrollt; kein Unterdrueckungskommentar, um die Zahl zu schoenen. **Das Tor hat sich selbst bewaehrt:** der erste Entwurf eines Waechters erzeugte einen neuen Lint-Fund (430 statt 429) und wurde von der Verifikation des Plans gefangen; die Reparatur brach `tsc`, weil `@types/node-forge` `Bag.cert` als `Certificate | undefined` deklariert, waehrend die Bibliothek zur Laufzeit `null` zuweist — Endfassung prueft beides. **Zahlen:** 434 → 429, `noArrayIndexKey` unveraendert 19 (alle geprueft, alle harmlos), `noNonNullAssertion` 11 → 6, web-Tests 68/481 → 69/484, api 72/1137 → 72/1143, type-check 4/4, lint 5/5. | 2026-09-21 | 8716fa5,b4aaed4,27909e4,de69863 | [260921-iwr-listenschluessel-per-positionsnummer-und](./quick/260921-iwr-listenschluessel-per-positionsnummer-und/) |
 | 260921-jt4 | **Barrierefreiheit von 30 auf 1 Befund, plus die vier zurueckgestellten Restposten.** Die 30 a11y-Befunde galten seit bi2 als "braucht Bedienentscheidungen"; die hat der Orchestrator getroffen, und der Planer hat **zwei davon widerlegt**: (1) Der vorgesehene Rueckfallweg (`role` + `tabIndex` + Tastaturhandler, wo kein echter Knopf geht) tauscht gemessen drei Befunde gegen einen neuen `useSemanticElements` — eine Regel, die bi2 gerade erst auf 0 gebracht hatte; wird nirgends benutzt, fuer den Verschachtelungsfall (Marktplatz-Karte) tritt eine deckende Geschwister-Schaltflaeche an seine Stelle. (2) **Vier der elf "Klick"-Befunde sind gar keine Klicks**, sondern `onError`-Handler an `<img>` — da gibt es keinen Tastaturweg zu schaffen, sie bekommen `aria-hidden`. **Ein Fund darueber hinaus:** alle fuenf ARIA-Befunde sind `aria-label` auf rollenlosen Elementen — die werden von Vorleseprogrammen still verworfen, die Beschriftungen kamen also bei niemandem an; jetzt mit korrekter Rolle. Sechs Stellen wurden zu echten `<button>` (Aussehen unveraendert), vier `autoFocus` auf Seiten entfernt (auf Seiten reisst er beim Laden den Fokus an sich — im Dialog waere er richtig gewesen, alle vier waren Seiten). **Ein Befund bleibt bewusst stehen und bleibt gezaehlt** (`calculator-widget.tsx:323`), samt ausdruecklich verworfener Umgehung. **Restposten:** ZIP-Name uebersetzt mit getesteter Schutzfunktion `zip-filename.ts` (der frueher genannte Umlaut-Einwand trifft fuer "Zertifikate.zip" nicht zu, die Schutzfunktion sichert kuenftige Uebersetzungen ab); die ueberfluessige `case`-Marke im Normalisierer aufgeloest, Absicht in den Kommentar gewandert; Kalender-Verschwendung abgestellt. **Zur `t`-Frage eine Korrektur an gof:** `use-intl` 4.13 erzeugt `t` in einem `useMemo`, es ist also in der Bibliothek stabil — instabil ist es nur in den Test-Attrappen, und daher kam der Beleg von damals. Die acht Korrekturen aus gof bleiben richtig und schaedlich sind sie nicht, aber die Begruendung war zu breit; ein Test an der Wurzel misst es jetzt. **Laufzeitnachweis vom Orchestrator** (Browser, 90 Tage Vorschau — bei der Voreinstellung 30 tritt der Doppelabruf gar nicht auf, die Messung haette also nichts gezeigt): drei Monatswechsel holen `calendar/sources` nur noch **1x statt 4x**, und der Termin-Abruf mit identischem Zeitraum ist weg (3 Klicks → 2 Abrufe statt 3). Der 5-Minuten-Auffrischer bleibt unangetastet — belegt nicht durch Warten im Browser (zwei Messversuche waren ungueltig, weil das Werkzeug die Seite zwischendurch neu laedt: nach 330 s Wartezeit war das Dokument 37 s alt), sondern durch Test 19 mit gestellter Uhr: nach `advanceTimersByTime(300_000)` werden **beide** Abrufe erneut ausgefuehrt. **Zahlen:** 429 → 399, a11y 30 → 1, web-Tests 69/484 → 73/529, api 72/1143 unveraendert, type-check 4/4, lint 5/5, keine neuen Unterdrueckungen. | 2026-09-21 | a8531d4,3d0bc0b,0c89c13,b601141,e651c24,+7 | [260921-jt4-barrierefreiheit-mit-bedienentscheidunge](./quick/260921-jt4-barrierefreiheit-mit-bedienentscheidunge/) |
+| 260921-ldf | **Der Wackeltest war ein echter Produktfehler — nachgewiesen, nicht vermutet.** CI-Lauf 395 war rot; durchgefallen war ein Test aus quick-260914-m97, rund einmal in 17 vollen Laeufen, isoliert nie. Symptom: Vorschaubild da, Haekchen "Bildschirmfoto anhaengen" aus. **Ursache:** der Fehler-melden-Dialog war dauerhaft eingehaengt, sein `useState(screenshot !== null)` lief damit genau einmal — beim allerersten Laden der Seite, als noch kein Bild existierte — und der richtige Wert wurde erst von einem `useEffect` nachgezogen, der bauartbedingt nach dem Commit laeuft. **Beleg, deterministisch statt statistisch:** ein MutationObserver ueber jeden einzelnen DOM-Commit zeigt gegen den alten Stand, ohne jede kuenstliche Verzoegerung: `COMMIT dialog=true img=ja box=AUS` gefolgt von `COMMIT dialog=true img=ja box=AN`. Der falsche Zustand entsteht bei JEDEM Oeffnen, nicht nur unter Last, und haelt zwei Makrotask-Runden — dazwischen darf der Browser zeichnen, ein Nutzer kann es also sehen. **Ehrliche Einordnung der Tragweite:** die Korrektur kommt binnen Millisekunden, lange bevor jemand "Senden" treffen kann. Der befuerchtete Fall (Bild gesehen, abgeschickt, Bild fehlt) ist NICHT erreichbar; es bleibt ein kurzes Flackern. Repariert wurde trotzdem der Produktcode, nicht der Test — wer einen wirklich vorhandenen falschen Zustand im Test wegberuhigt, laesst ihn stehen. **Zwei Teilursachen, einzeln reicht keine:** der Dialog wird nur noch eingehaengt, solange er offen ist (frischer Mount je Oeffnen, der zuruecksetzende Effekt entfaellt), und das Haekchen wird beim Rendern abgeleitet statt nachgezogen. Dieselbe Ursache lag an einer zweiten Stelle: nach einem Versand stand beim erneuten Oeffnen zwei Runden lang der alte Danke-Bildschirm im DOM. **Zur Statistik, weil es der Kern der Sache ist:** 20 volle Laeufe ohne Fehlschlag gelten ausdruecklich NICHT als Beweis — bei der Ausgangsrate 1:17 waeren sie auch ohne Reparatur zu rund 30 Prozent zu erwarten. Tragend ist, dass der falsche Zwischenzustand nicht mehr existiert und die neuen Tests gegen den alten Stand 5 von 5 rot sind. Kein `retry`, kein hoeheres Zeitlimit — die Ursache war nie blosse Zeit. **Zwei Konstruktionsfehler des Tests mitbehoben:** das `expect` innerhalb der Attrappe (wirft es, landet der Fehler mitten im `await` von `captureScreenshot`, dessen `catch` still `null` liefert — der Test waere viel spaeter mit "kein Vorschaubild" durchgefallen, also in die falsche Richtung zeigend) und die per `Object.defineProperty` gesetzte `document.body`-Groesse, die `cleanup()` ueberlebte und alle zwoelf folgenden Tests derselben Datei 3200x1000 sehen liess. **Widerlegt unterwegs:** der Verdacht auf den dynamischen Import von `html-to-image` — er loest auf, bevor ein zuvor gesetzter `setTimeout(0)` feuert, ueberschreitet also keine Makrotask-Grenze. **Zahlen:** Warnungen 399 unveraendert, web-Tests 529 → 531, api 72/1143 unveraendert, type-check 4/4, lint 5/5. | 2026-09-21 | c0ab5b5,de7fdb7,9f02fcc,a6181e2 | [260921-ldf-wackeltest-fehler-melden-haekchen-bildsc](./quick/260921-ldf-wackeltest-fehler-melden-haekchen-bildsc/) |
 
 ## Deferred Items
 
@@ -497,4 +498,4 @@ Last session: 2026-09-21T04:50:00Z
 Resumed: 2026-09-21 — Sitzung ueber /gsd-resume-work fortgesetzt. Stand geprueft: Arbeitsbaum sauber, main == origin/main auf 55aa287, CI-Lauf 387 fuer 55aa287 erfolgreich (Beta-Images gebaut). Push und CI aus dem letzten Stopp-Punkt sind damit erledigt.
 Stopped at: Warte auf Nutzerentscheidung, womit weitergearbeitet wird. Offen fuer den User: alpha pullen (web+api) und danach am Windows-VM-Client die echte Fehlermeldung schicken (Betreff `[Desktop/Windows]` + `Herkunft:`-Zeile pruefen); eigenen Arbeitsplatz-Client einmal per Browser-Installer erneuern; Freigabe 1.3.0 auf Zuruf. Technisch offen im Ledger: WINDOWS #35 (Biome laeuft nicht — biome.json:3 `organizeImports` ist in Biome 2.5.0 unbekannt, `biome check` bricht mit Konfigurationsfehler ab, reproduziert 2026-09-21) und WINDOWS #36 (403-Antworten bleiben in handleSubmit/handleDelete ohne sichtbare Reaktion).
 Resume file: None
-Last activity: 2026-09-21 - Quick 260921-jt4: Barrierefreiheit 30 → 1 Befund und die vier Restposten erledigt; zwei Vorgaben des Orchestrators vom Planer widerlegt (Rueckfallweg erzeugt neue Befunde, vier vermeintliche Klicks sind onError-Handler). Kalender-Verschwendung im Browser nachgemessen, 5-Minuten-Auffrischer per gestellter Uhr als intakt belegt
+Last activity: 2026-09-21 - Quick 260921-ldf: der Wackeltest aus CI-Lauf 395 war ein echter Produktfehler — der Fehler-melden-Dialog stand bei jedem Oeffnen kurz mit ausgeschaltetem Haekchen da; Ursache behoben, nicht der Test beruhigt

.planning/debug/knowledge-base.md

@@ -0,0 +1,19 @@
+# GSD Debug Knowledge Base
+
+Geloeste Debug-Sitzungen. Wird von `gsd-debugger` zu Beginn einer neuen
+Untersuchung gelesen, um bekannte Muster als Hypothesen-Kandidaten
+vorzuschlagen.
+
+---
+
+## wackeltest-bugreport-haekchen — Vorschaubild sichtbar, Haekchen "Bildschirmfoto anhaengen" aus (Wackeltest CI 395)
+- **Date:** 2026-09-21
+- **Error patterns:** toBeChecked, Received element is not checked, flaky, Wackeltest, nur unter Last, isoliert nie, Zustand erst einen Commit spaeter richtig
+- **Root cause(s):** Dialog dauerhaft eingehaengt, sodass `useState(abgeleiteterWert)` nur beim allerersten Mount lief (Daten noch nicht da); zusammen damit: Anfangszustand per `useEffect` nachgezogen, und passive Effekte laufen NACH dem Commit — React schreibt deshalb bei jedem Oeffnen erst den falschen, dann den richtigen Zustand in den DOM
+- **Fix:** Dialog nur einhaengen, solange offen (`{open && <Dialog/>}`) — frischer Mount je Oeffnen; abgeleiteten Wert beim Rendern ableiten statt per Effekt nachziehen (`const attach = screenshot !== null && (attachChoice ?? true)`); zuruecksetzender Effekt entfaellt ersatzlos
+- **Files changed:** apps/web/src/components/bug-report/bug-report-dialog.tsx, apps/web/src/components/bug-report/bug-report-button.tsx, apps/web/src/components/bug-report/bug-report-button.test.tsx
+- **Why not caught:** Es gab ein Tor, aber ein stumpfes — Test 1 las den DOM EINMAL nach `findByRole` und traf damit mal den falschen ersten, meist den richtigen zweiten Commit (1:17). Eine Stichprobe am Ende kann einen falschen Zwischen-Commit grundsaetzlich nicht zuverlaessig sehen. Lint und Typpruefung koennen diese Klasse gar nicht sehen.
+- **Recurrence guard:** Regressionstest apps/web/src/components/bug-report/bug-report-button.test.tsx:"Test 14 (quick-260921-ldf): kein falscher Zwischenzustand" und ":"Test 15 (quick-260921-ldf): erneutes Oeffnen startet frisch" — beide beobachten per MutationObserver JEDEN Commit statt einer Stichprobe und sind gegen den Stand davor deterministisch rot (5/5)
+- **Merksatz fuer aehnliche Faelle:** Bei einem Wackeltest zuerst per MutationObserver pruefen, ob der beobachtete Zwischenzustand ueberhaupt in den DOM geschrieben wird. Wird er es, ist es ein Produktfehler und der Test hat recht — dann nicht den Test beruhigen (kein retry, kein hoeheres Zeitlimit), sondern den Zustand beseitigen.
+---
+

.planning/debug/resolved/wackeltest-bugreport-haekchen.md

@@ -0,0 +1,149 @@
+---
+status: resolved
+trigger: "CI 395 rot: apps/web/src/components/bug-report/bug-report-button.test.tsx Test 1 -- Vorschaubild da, Haekchen 'Bildschirmfoto anhaengen' aus. 1 Fehlschlag in ~17 vollen Laeufen, isoliert nie."
+created: 2026-09-21T00:00:00Z
+updated: 2026-09-21T00:00:00Z
+symptoms_prefilled: true
+goal: find_and_fix
+---
+
+## Current Focus
+
+reasoning_checkpoint:
+  hypothesis: "attach ist abgeleiteter Zustand, der per passivem useEffect nachgezogen wird. Da BugReportDialog dauerhaft eingehaengt ist, laeuft useState(screenshot !== null) nur beim ersten Mount (screenshot noch null) -> attach startet immer false. Deshalb committet React BEI JEDEM Oeffnen zuerst einen DOM-Zustand 'Dialog offen + Bild da + Haekchen AUS' und korrigiert ihn erst im naechsten Commit."
+  confirming_evidence:
+    - "MutationObserver-Protokoll (H2): COMMIT dialog=true img=ja box=AUS, danach COMMIT dialog=true img=ja box=AN -- der falsche Zustand ist ein echter, committeter DOM-Zustand, kein Testartefakt."
+    - "H3 (roher Klick ohne act): der falsche Zustand haelt ZWEI volle Makrotask-Runden. Zwei Makrotask-Grenzen = zwei Gelegenheiten des Browsers zu zeichnen."
+    - "H1 (kuenstlicher Makrotask im toPng-Mock): Fehlschlag 4 von 4, exakt dieselbe Meldung wie in CI 395 -- die Wackelbedingung ist reine Beobachtungszeit."
+    - "H3b: dasselbe Muster beim erneuten Oeffnen -- der alte Danke-Bildschirm steht zwei Runden lang im DOM, bevor das frische Formular erscheint."
+  falsification_test: "Waere es ein reines Testartefakt, duerfte im MutationObserver-Protokoll kein Commit mit img=ja/box=AUS auftauchen. Er taucht auf, ausnahmslos, bei jedem Oeffnen."
+  fix_rationale: "Ursache ist die Konstruktion: Zustand wird per Effekt nachgezogen statt beim Rendern abgeleitet, und der Dialog bleibt ueber das Schliessen hinaus eingehaengt. Beides beseitigen: (1) attach waehrend des Renderns aus screenshot ableiten, (2) den Dialog nur einhaengen, solange er offen ist -> jeder Oeffnungsvorgang startet mit frischem Zustand, schon im ersten Commit."
+  blind_spots: "Ob der Browser den Zwischen-Frame tatsaechlich zeichnet, ist hier nicht im echten Browser gemessen -- belegt ist, dass der falsche Zustand zwei Makrotask-Grenzen ueberdauert, also mindestens zwei Zeichengelegenheiten offenstehen."
+  candidate_causes:
+    - "code: abgeleiteter Zustand per passivem Effekt statt beim Rendern (bestaetigt)"
+    - "code: Dialog dauerhaft eingehaengt -> useState-Startwert veraltet (bestaetigt, zweite Teilursache)"
+    - "environment: Ereignisschleifen-Last im vollen Vitest-Lauf (nur Ausloeser der Beobachtung, nicht Ursache)"
+    - "data: Datenform des Bildes -- ausgeschlossen, img src ist im Fehlerfall korrekt"
+  and_gate: "ja -- zwei Bedingungen zusammen: (a) attach wird per Effekt nachgezogen UND (b) der Dialog bleibt eingehaengt, sodass der useState-Startwert aus der Zeit vor dem ersten Bild stammt. Ohne (b) waere (a) beim ersten Oeffnen unauffaellig; ohne (a) waere (b) folgenlos."
+test: Fix anwenden, danach H2/H3-Instrumentierung erneut laufen lassen
+expecting: Erster Commit mit Dialog traegt bereits Haekchen AN
+next_action: bug-report-dialog.tsx und bug-report-button.tsx anpassen
+
+## Symptoms
+
+expected: Nach Klick auf den Fehler-melden-Knopf oeffnet der Dialog mit Vorschaubild UND gesetztem Haekchen "Bildschirmfoto anhaengen".
+actual: Vorschaubild ist da (img src == DATA_URL, Checkbox nicht disabled), aber die Checkbox ist nicht checked.
+errors: |
+  Error: expect(element).toBeChecked()
+  Received element is not checked:
+    <input class="h-4 w-4" id="bug-report-attach" type="checkbox" />
+  bug-report-button.test.tsx:126:72
+reproduction: pnpm --filter @tessera/web exec vitest run (voller Lauf), ~1 von 17. Isoliert (nur die Datei) in 6 Laeufen nie.
+started: CI-Lauf 395 (2026-09-21), Test existiert seit quick-260914-m97
+
+## Eliminated
+
+- hypothesis: "Reines Testartefakt -- die Pruefung misst einen Zustand, den der Nutzer nie sieht"
+  evidence: "MutationObserver-Protokoll zeigt den Zustand als echten DOM-Commit, der zwei Makrotask-Runden ueberdauert. Der Browser hat in dieser Zeit mindestens zwei Zeichengelegenheiten."
+  timestamp: T2
+
+- hypothesis: "Der dynamische Import von html-to-image kostet einen Makrotask und kippt dadurch die Reihenfolge"
+  evidence: "Gemessen: await import('html-to-image') loest ohne Makrotask-Grenze auf (Timer 0, davor gesetzt, feuert NACH dem Import). Der Import ist nicht die Ursache -- die falsche Reihenfolge besteht auch ohne ihn."
+  timestamp: T2
+
+## Evidence
+
+- timestamp: T0
+  checked: apps/web/src/components/bug-report/bug-report-button.tsx
+  found: "handleClick: setCapturing(true); const shot = await captureScreenshot(); setScreenshot(shot); setOpen(true); setCapturing(false). BugReportDialog wird IMMER gerendert (kein bedingtes Mounten) -- die Instanz bleibt ueber open-Wechsel hinweg bestehen."
+  implication: "useState(screenshot !== null) im Dialog laeuft nur EINMAL, beim ersten Mount des Knopfs, da ist screenshot noch null -> attach startet IMMER false. Das Haekchen wird ausschliesslich durch den useEffect gesetzt."
+
+- timestamp: T0
+  checked: apps/web/src/components/bug-report/bug-report-dialog.tsx
+  found: "const [attach, setAttach] = useState(screenshot !== null); useEffect(() => { if (open) { ... setAttach(screenshot !== null); ... } }, [open, screenshot]);"
+  implication: "attach ist abgeleiteter Zustand, synchronisiert per passivem Effekt. Zwischen dem Commit (Bild im DOM) und dem Lauf des passiven Effekts (Haekchen an) existiert zwangslaeufig ein Zustand 'Bild da, Haekchen aus'."
+
+- timestamp: T0
+  checked: apps/web/src/lib/bug-report-api.ts captureScreenshot
+  found: "await import('html-to-image') -- dynamischer Import VOR dem toPng-Aufruf; Fehler werden geschluckt (catch -> null)."
+  implication: "Zwei await-Stufen vor setScreenshot/setOpen. Unter Last kann die Aufloesung nach dem Ende des act()-Bereichs von user.click() landen."
+
+- timestamp: T1
+  checked: "Kuenstlicher Makrotask im toPng-Mock (zz-repro.test.tsx, Verzoegerung 0/1/5/20 ms)"
+  found: "4 von 4 Fehlschlaegen mit exakt der CI-Meldung 'Received element is not checked'."
+  implication: "Jede Makrotask-Grenze in der Aufnahmekette genuegt, damit die Pruefung den falschen Zwischenzustand sieht. Die Last im vollen Lauf ist nur der Ausloeser."
+
+- timestamp: T2
+  checked: "MutationObserver ueber document.body waehrend des Oeffnens (zz-repro3.test.tsx), toPng rein mikrotask wie im echten Test"
+  found: |
+    COMMIT dialog=false img=nein box=-
+    COMMIT dialog=false img=nein box=-
+    COMMIT dialog=true  img=ja   box=AUS   <- falscher Zustand, committet
+    COMMIT dialog=true  img=ja   box=AN
+  implication: "Der Zustand 'Bild da, Haekchen aus' ist ein echter, committeter DOM-Zustand -- bei JEDEM Oeffnen, nicht nur unter Last. Der Test faellt nur dann durch, wenn er zufaellig den ersten statt den zweiten Commit sieht."
+
+- timestamp: T2
+  checked: "Roher Klick ohne act(), Sampling pro Makrotask-Runde (zz-repro4.test.tsx)"
+  found: "runde 1: bild=ja haekchen=AUS | runde 2: bild=ja haekchen=AUS | runde 3: bild=ja haekchen=AN"
+  implication: "Der falsche Zustand ueberdauert zwei volle Ereignisschleifen-Runden. Im Browser liegen damit mindestens zwei Zeichengelegenheiten in diesem Zustand -> fuer den Nutzer sichtbar."
+
+- timestamp: T2
+  checked: "Erneutes Oeffnen nach Versand (zz-repro4.test.tsx, H3b)"
+  found: "runde 2 und 3 zeigen den ALTEN Danke-Bildschirm (danke=true), erst runde 4 das frische Formular."
+  implication: "Zweite Auspraegung derselben Ursache: auch status/description werden erst per Effekt zurueckgesetzt. Der Fix muss beide Teilursachen beseitigen."
+
+- timestamp: T2
+  checked: "await import('html-to-image') gegen setTimeout(0) (zz-repro2.test.tsx)"
+  found: "[IMPORT-1] timerFired=false 1.13ms, [IMPORT-2] timerFired=false 0.18ms"
+  implication: "Der dynamische Import ueberschreitet keine Makrotask-Grenze -- er ist nicht die Ursache."
+
+## Resolution
+
+root_cause: |
+  Produktfehler, zwei Teilursachen im UND-Verbund (bestaetigt per MutationObserver
+  ueber jeden DOM-Commit):
+  (a) BugReportDialog war dauerhaft eingehaengt und gab bei geschlossenem Zustand
+      nur `null` zurueck. `useState(screenshot !== null)` lief damit genau einmal,
+      beim allerersten Mount des Knopfs -- da war `screenshot` noch `null`, also
+      startete `attach` immer als `false`.
+  (b) Der Anfangszustand wurde per `useEffect` nachgezogen. Passive Effekte laufen
+      NACH dem Commit. React schrieb deshalb bei JEDEM Oeffnen zuerst den Zustand
+      "Dialog offen + Vorschaubild sichtbar + Haekchen AUS" in den DOM und
+      korrigierte ihn erst im naechsten Commit.
+  Der falsche Zustand ueberdauerte gemessen zwei volle Makrotask-Runden -- der
+  Browser hat in dieser Zeit mindestens zwei Gelegenheiten, ihn zu zeichnen.
+  Die Last im vollen Vitest-Lauf war nur der Ausloeser dafuer, dass die Pruefung
+  den ersten statt den zweiten Commit sah; sie war nie die Ursache.
+
+fix: |
+  (a) Der Dialog wird nur noch eingehaengt, solange er offen ist
+      (`{open && <BugReportDialog ... />}`) -- jedes Oeffnen ist ein frischer
+      Mount, der Anfangszustand gilt schon im ersten Commit. Der zuruecksetzende
+      Effekt entfaellt ersatzlos.
+  (b) Das Haekchen wird beim Rendern aus `screenshot` abgeleitet statt per Effekt
+      nachgezogen: `const attach = screenshot !== null && (attachChoice ?? true)`.
+      `attachChoice` haelt allein die bewusste Abwahl des Nutzers.
+
+verification: |
+  signal_reproduktion: bestaetigt -- kuenstlicher Makrotask in der Aufnahmekette
+    erzwang den Fehlschlag 4/4 vor dem Fix, 4/4 gruen danach.
+  signal_regressionstest: Test 14/15 sind gegen den Stand vor dem Fix in 5 von 5
+    Laeufen rot, danach gruen. Deterministisch, kein retry, kein Zeitlimit.
+  signal_umkehrprobe: Quellcode auf 8d604b8 zurueckgesetzt, neue Tests bleiben --
+    der Fehler kehrt zurueck. Fix und Fehler haengen nachweislich zusammen.
+  signal_zwischenzustand: MutationObserver-Protokoll nach dem Fix zeigt den
+    ersten Commit mit Dialog bereits als "img=ja box=AN". Kein falscher Commit mehr.
+  signal_kein_loeschfix: der Diff ist kein Wegnehmen einer Pruefung -- Test 1
+    prueft unveraendert dieselbe Zusicherung, zwei Tests kamen hinzu.
+  gates: lint 5/5 ohne Fehlerstufe, 399 Warnungen (unveraendert); type-check 4/4;
+    apps/web 73 Dateien / 531 Tests; apps/api 72 Dateien / 1143 Tests.
+  signal_stabilitaet: 20/20 volle Laeufe von `pnpm --filter @tessera/web exec vitest run`
+    gruen, 0 Fehlschlaege, je 531 Tests. Fuer sich genommen schwach (bei 1:17 waeren
+    20 gruene Laeufe auch ohne Fix zu ~30 % zu erwarten) -- der tragende Beleg ist
+    der deterministische: den falschen Zustand gibt es nicht mehr.
+  guardrail_verdict: accepted
+
+files_changed:
+  - apps/web/src/components/bug-report/bug-report-dialog.tsx
+  - apps/web/src/components/bug-report/bug-report-button.tsx
+  - apps/web/src/components/bug-report/bug-report-button.test.tsx

.planning/quick/260921-ldf-wackeltest-fehler-melden-haekchen-bildsc/260921-ldf-SUMMARY.md

@@ -0,0 +1,150 @@
+---
+phase: quick-260921-ldf
+plan: 01
+subsystem: ui
+tags: [react, vitest, flaky-test, bug-report, state-management, react-effects]
+
+requires:
+  - phase: quick-260914-m97
+    provides: "Fehler-melden-Knopf mit Bildaufnahme VOR dem Dialog; Test 1 als Zusicherung dieser Reihenfolge"
+  - phase: quick-260918-gza
+    provides: "Vier Herkunftsfelder in der Nutzlast (Test 12/13 derselben Datei)"
+provides:
+  - "Wackeltest aus CI-Lauf 395 ursaechlich beseitigt — als Produktfehler, nicht als Testfehler"
+  - "Fehler-melden-Dialog zeigt Vorschaubild und Haekchen ab dem ERSTEN Commit stimmig, statt einen Commit spaeter"
+  - "Erneutes Oeffnen nach einem Versand zeigt keinen alten Danke-Bildschirm und keinen alten Text mehr"
+  - "Test 14/15: MutationObserver-Pruefung ueber JEDEN Commit statt einer Stichprobe am Ende — deterministisch rot vor dem Fix"
+  - "Zwei Konstruktionsfehler im Fehler-melden-Test behoben (expect in der Attrappe, nicht zurueckgesetzte document.body-Groesse)"
+affects: [web-bug-report, web-test-hygiene]
+
+actuals:
+  tokens: 11800
+  tasks: 1
+  commits: 3
+
+tech-stack:
+  added: []
+  patterns:
+    - "Abgeleiteten Zustand beim RENDERN ableiten, nicht per useEffect nachziehen: passive Effekte laufen nach dem Commit, also schreibt React zwangslaeufig erst den falschen und dann den richtigen Zustand in den DOM. Muster hier: `const attach = screenshot !== null && (attachChoice ?? true)` — eine eigene Zustandsvariable haelt nur noch die bewusste Wahl des Nutzers, nicht den abgeleiteten Wert."
+    - "Dialoge nur einhaengen, solange sie offen sind (`{open && <Dialog ... />}`), statt sie dauerhaft eingehaengt zu lassen und `null` zurueckgeben zu lassen. Sonst laufen die useState-Startwerte genau einmal — zu einem Zeitpunkt, an dem die spaeteren Daten noch nicht da sind — und jedes weitere Oeffnen braucht einen zuruecksetzenden Effekt, der genau diese Luecke aufreisst."
+    - "Wackeltests mit einem MutationObserver ueber JEDEN DOM-Commit untersuchen statt mit einer Stichprobe am Ende. Der Unterschied zwischen 'der Nutzer sieht das nie' und 'das steht bei jedem Oeffnen im DOM' ist genau so zu messen und nicht anders zu erraten."
+    - "Wackelursache einkreisen, indem man die Beobachtungszeit kuenstlich verschiebt (ein setTimeout in der Attrappenkette) statt auf einen Zufallstreffer unter Last zu warten: aus 1:17 wird 4 von 4."
+    - "Kein expect() innerhalb einer Attrappe, die in einem await der Komponente laeuft — ein Fehler daraus wird von einem catch in der Produktionskette verschluckt und der Test faellt an ganz anderer Stelle mit irrefuehrender Meldung durch. Beobachtung festhalten, im Testkoerper pruefen."
+    - "Object.defineProperty auf document.body (scrollWidth/scrollHeight) ueberlebt cleanup() und damit die ganze Testdatei — in afterEach per Reflect.deleteProperty zuruecknehmen."
+
+key-files:
+  created: []
+  modified:
+    - apps/web/src/components/bug-report/bug-report-dialog.tsx
+    - apps/web/src/components/bug-report/bug-report-button.tsx
+    - apps/web/src/components/bug-report/bug-report-button.test.tsx
+
+key-decisions:
+  - "Urteil Produktfehler, nicht Testfehler — und zwar gemessen, nicht geschaetzt: ein MutationObserver ueber jeden Commit zeigt den Zustand 'Vorschaubild sichtbar, Haekchen aus' bei JEDEM Oeffnen als echten, festgeschriebenen DOM-Zustand, nicht nur unter Last. Ohne act() haelt er zwei volle Makrotask-Runden."
+  - "Repariert wurde der Ursache-Code, nicht der Test. Test 1 prueft unveraendert dieselbe Zusicherung; kein retry, kein hoeheres Zeitlimit — die Ursache war nie blosse Zeit, sondern ein falscher Zustand, den es jetzt nicht mehr gibt."
+  - "Beide Teilursachen beseitigt, nicht nur eine. Die abgeleitete Ableitung allein wuerde die Abwahl des Nutzers ueber das Schliessen hinaus festhalten; das bedingte Einhaengen allein liesse den Fehler wiederkehren, falls Bild und Oeffnen je in getrennten Commits landeten. Erst zusammen ist die Zusicherung strukturell erzwungen."
+  - "Der zuruecksetzende useEffect entfaellt ersatzlos statt umgebaut zu werden — ein frischer Mount setzt Status, Text, Fehlerstand und Haekchen schon durch die useState-Startwerte zurueck."
+  - "Die geschluckte Ausnahme in captureScreenshot (catch liefert null) bleibt bewusst stehen: das Bild ist eine Beigabe, der Bericht geht auch ohne. Angepasst wurde stattdessen der Test, der sein expect in diese Kette gelegt hatte."
+
+patterns-established:
+  - "Bei einem Wackeltest zuerst fragen, ob der beobachtete Zwischenzustand ueberhaupt in den DOM geschrieben wird. Wird er es, ist es ein Produktfehler und der Test hat recht behalten — auch wenn die sichtbare Wirkung nur ein kurzes Flackern ist."
+
+requirements-completed: [Ursache, Urteil, Reparatur, Nebenbefund-1, Nebenbefund-2, Stabilitaet]
+
+duration: ~1h (eine Sitzung)
+completed: 2026-09-21
+status: complete
+---
+
+# Quick-Vorgang 260921-ldf: Wackeltest Fehler-melden-Haekchen Summary
+
+**Der Wackeltest hatte recht: der Fehler-melden-Dialog schrieb bei JEDEM Oeffnen zuerst den Zustand "Vorschaubild sichtbar, Haekchen aus" in den DOM und korrigierte ihn erst einen Commit spaeter — ein Produktfehler, kein Testfehler. Repariert ist der Ursache-Code; der Test prueft unveraendert dasselbe und wackelt nicht mehr.**
+
+## Die Ursache in einem Satz
+
+Der Dialog war dauerhaft eingehaengt, sodass `useState(screenshot !== null)` nur ein einziges Mal lief — beim allerersten Mount des Knopfs, als noch gar kein Bild da war — und der richtige Wert erst von einem `useEffect` nachgezogen wurde, der per Bauart NACH dem Commit laeuft.
+
+## Das Urteil: Produktfehler
+
+Das war die eigentliche Frage, und sie ist gemessen worden statt geschaetzt. Ein `MutationObserver` ueber `document.body` protokolliert jeden einzelnen DOM-Commit waehrend des Oeffnens. Gegen den Stand vor dem Fix, mit einer Attrappe, die rein in Mikrotasks aufloest, also ohne jede kuenstliche Verzoegerung:
+
+```
+COMMIT dialog=false img=nein box=-
+COMMIT dialog=false img=nein box=-
+COMMIT dialog=true  img=ja   box=AUS   <- falsch, aber festgeschrieben
+COMMIT dialog=true  img=ja   box=AN
+```
+
+Der falsche Zustand ist also kein Testartefakt und keine Frage der Last. Er entsteht bei **jedem** Oeffnen. Ein zweiter Versuch, diesmal mit einem rohen Klick ohne `act()` und einer Stichprobe pro Ereignisschleifen-Runde, zeigt, wie lange er haelt:
+
+```
+runde 1  bild=ja haekchen=AUS
+runde 2  bild=ja haekchen=AUS
+runde 3  bild=ja haekchen=AN
+```
+
+Zwei volle Makrotask-Runden. Zwischen zwei Makrotasks darf der Browser zeichnen — der Nutzer kann diesen Zustand also sehen. Damit ist die Kernfrage beantwortet: **ja, ein echter Nutzer geraet in diesen Zustand.**
+
+Was dabei ehrlich dazugehoert: die Korrektur kommt binnen Millisekunden, lange bevor jemand "Senden" druecken kann. Der befuerchtete Fall — jemand sieht sein Bild, schickt ab, und das Bild fehlt — ist damit nicht erreichbar. Was bleibt, ist ein kurzes Flackern beim Oeffnen. Echt, sichtbar, aber ohne Datenverlust. Der Grund, es trotzdem im Produktcode zu reparieren statt im Test: der Test hat einen wirklich vorhandenen falschen Zustand gefunden, und wer ihn im Test wegberuhigt, laesst den Zustand stehen.
+
+Nicht gemessen und deshalb hier auch nicht behauptet: ob der Browser den Zwischenschritt tatsaechlich in jedem Fall zeichnet. Belegt ist, dass er zwei Zeichengelegenheiten lang besteht.
+
+## Wie die Ursache gefunden wurde
+
+Drei Schritte, jeder mit einem eigenen Messergebnis:
+
+1. **Beobachtungszeit kuenstlich verschoben.** Statt auf einen Zufallstreffer unter Last zu warten, bekam die `toPng`-Attrappe ein `setTimeout` in die Kette. Ergebnis: 4 von 4 Fehlschlaegen mit exakt der CI-Meldung, schon bei 0 ms. Damit war klar, dass die Last nur der Ausloeser ist und jede Makrotask-Grenze genuegt.
+2. **Eine naheliegende Erklaerung widerlegt.** Der Verdacht lag auf `await import('html-to-image')` in `captureScreenshot`. Gemessen: der Import loest auf, bevor ein zuvor gesetzter `setTimeout(0)` feuert — er ueberschreitet keine Makrotask-Grenze und ist nicht die Ursache.
+3. **Jeden Commit protokolliert.** Erst das zeigte, dass der falsche Zustand nicht gelegentlich unter Last entsteht, sondern immer.
+
+Dabei fiel eine zweite Auspraegung derselben Ursache auf: beim erneuten Oeffnen nach einem Versand stand zwei Runden lang der **alte Danke-Bildschirm** im DOM, bevor das frische Formular erschien. Auch `status`, `description` und `failedStatus` wurden erst per Effekt zurueckgesetzt.
+
+## Die Reparatur
+
+Zwei Teilursachen, beide beseitigt — einzeln reicht keine:
+
+- **`bug-report-button.tsx`:** Der Dialog wird nur noch eingehaengt, solange er offen ist. Jedes Oeffnen ist damit ein frischer Mount, und die `useState`-Startwerte gelten schon im ersten Commit. Der zuruecksetzende `useEffect` entfaellt ersatzlos — er hatte genau die Luecke aufgerissen, die er schliessen sollte.
+- **`bug-report-dialog.tsx`:** Das Haekchen wird beim Rendern abgeleitet statt nachgezogen: `const attach = screenshot !== null && (attachChoice ?? true)`. `attachChoice` haelt nur noch die bewusste Abwahl des Nutzers.
+
+Nach dem Fix zeigt dasselbe Commit-Protokoll den ersten Commit mit Dialog bereits als `img=ja box=AN`, und der rohe Klick ist schon in Runde 1 richtig. Es gibt keinen falschen Zwischenzustand mehr, den man beobachten koennte — deshalb kann der Test auch nicht mehr wackeln.
+
+## Der Nachweis: Test 14 und 15
+
+Der alte Test 1 fand den Fehler nur durch Zufall — er las den DOM einmal, nachdem `findByRole` den Dialog gemeldet hatte, und traf mal den falschen ersten, meist den richtigen zweiten Commit. Ein Fehlschlag auf rund siebzehn volle Laeufe.
+
+Die beiden neuen Tests pruefen stattdessen **jeden** Commit und dulden keinen einzigen mit sichtbarem Bild und ausgeschaltetem Haekchen. Test 14 deckt das erste Oeffnen ab, Test 15 das erneute Oeffnen nach einem Versand mit abgewaehltem Haekchen und getipptem Text.
+
+Gegen den Stand vor dem Fix (`8d604b8`, Quellcode zurueckgesetzt, Tests behalten) sind beide in **5 von 5 Laeufen rot**; mit dem Fix gruen. Kein `retry`, kein hoeheres Zeitlimit — beides waere hier auch falsch gewesen, weil die Ursache nie blosse Zeit war.
+
+Test 1 bleibt in der Sache unveraendert und prueft weiterhin dieselbe Zusicherung. Die Pruefmenge ist gewachsen, nicht geschrumpft.
+
+## Die zwei Nebenbefunde
+
+Beide waren nicht die Ursache, beide haetten die Suche in die Irre fuehren koennen. Beide sind erledigt (Commit `c0ab5b5`, vor dem Fix, unabhaengig davon gruen).
+
+**1. `expect` innerhalb der Attrappe.** Test 1 pruefte mitten in der `toPng`-Attrappe, dass noch kein Dialog im DOM steht. Wirft dieses `expect`, landet der Fehler mitten im `await` von `captureScreenshot`, und dessen `catch` liefert still `null` zurueck. Der Test waere dann nicht an der geprueften Stelle durchgefallen, sondern viel spaeter mit der Meldung, es gebe kein Vorschaubild — eine Meldung, die in die voellig falsche Richtung zeigt. Die Attrappe haelt die Beobachtung jetzt nur fest, geprueft wird im Testkoerper. Bewiesen wird dasselbe.
+
+**2. `document.body`-Groesse ohne Ruecknahme.** `scrollWidth`/`scrollHeight` wurden per `Object.defineProperty` auf 3200x1000 gesetzt und nie zurueckgenommen. Die eigene Eigenschaft verdeckt den Getter von `Element.prototype`, und `document.body` ueberlebt `cleanup()` — alle zwoelf folgenden Tests der Datei sahen weiterhin 3200x1000. `stubBodyGroesse` merkt sich das jetzt, `afterEach` nimmt es per `Reflect.deleteProperty` zurueck.
+
+## Commits
+
+1. **Zwei Konstruktionsfehler im Fehler-melden-Test behoben** — `c0ab5b5` (test)
+2. **Fehler-melden-Dialog stimmt ab dem ersten Commit, nicht erst einen spaeter** — `de7fdb7` (fix)
+3. **Test 14/15 halten jeden Commit fest statt nur den Endzustand** — `9f02fcc` (test)
+
+## Pruefstand
+
+- **`pnpm lint`:** 5/5 erfolgreich, keine Fehlerstufe, **399 Warnungen** — unveraendert, nicht gewachsen
+- **`pnpm type-check`:** 4/4 erfolgreich
+- **`apps/web`:** 73 Dateien / **531 Tests** (529 + Test 14/15), keine Datei dazugekommen oder weggefallen
+- **`apps/api`:** 72 Dateien / 1143 Tests, unveraendert — nicht beruehrt
+- **Stabilitaet:** **20 von 20** vollen Laeufen `pnpm --filter @tessera/web exec vitest run` gruen, 0 Fehlschlaege, je 531 Tests (je ~31 s, gegen den committeten Endstand, nacheinander)
+
+Dazu die ehrliche Einordnung: 20 saubere Laeufe sind fuer sich genommen **kein** starker Beleg. Bei der gemessenen Ausgangsrate von 1:17 waeren 20 gruene Laeufe auch ohne jede Reparatur noch mit rund 30 Prozent Wahrscheinlichkeit zu erwarten. Der eigentliche Beleg ist ein anderer und er ist deterministisch: der falsche Zwischenzustand existiert nicht mehr. Das Commit-Protokoll zeigt den ersten Commit mit Dialog bereits als `img=ja box=AN`, und Test 14/15 sind gegen den Stand davor in 5 von 5 Laeufen rot. Es gibt schlicht nichts mehr, was der Test zufaellig falsch antreffen koennte. Die 20 Laeufe bestaetigen das nur, sie tragen es nicht.
+
+## Was nicht angefasst wurde
+
+- Keine Versionsspruenge, keine neuen Abhaengigkeiten, kein repo-weites Umformatieren
+- `STATE.md` und `ROADMAP.md` unberuehrt (Sache des Orchestrators)
+- Nicht gepusht
+- Die geschluckte Ausnahme in `captureScreenshot` bleibt bewusst stehen — das Bild ist eine Beigabe, der Bericht geht auch ohne

apps/web/src/components/bug-report/bug-report-button.test.tsx

@@ -91,6 +91,27 @@ beforeEach(() => {
   vi.stubGlobal('fetch', mockFetch);
 });
 
+/**
+ * Groesse von `document.body` vortaeuschen. WICHTIG: `Object.defineProperty`
+ * legt eine eigene Eigenschaft auf dem Element an, die den Getter von
+ * `Element.prototype` verdeckt — `document.body` ueberlebt `cleanup()` und
+ * damit die ganze Datei. Ohne Ruecknahme saehen alle folgenden Tests 3200x1000.
+ * Deshalb merken und in `afterEach` wieder loeschen.
+ */
+let bodyGroesseVorgetaeuscht = false;
+function stubBodyGroesse(scrollWidth: number, scrollHeight: number) {
+  Object.defineProperty(document.body, 'scrollWidth', { value: scrollWidth, configurable: true });
+  Object.defineProperty(document.body, 'scrollHeight', { value: scrollHeight, configurable: true });
+  bodyGroesseVorgetaeuscht = true;
+}
+
+function restoreBodyGroesse() {
+  if (!bodyGroesseVorgetaeuscht) return;
+  Reflect.deleteProperty(document.body, 'scrollWidth');
+  Reflect.deleteProperty(document.body, 'scrollHeight');
+  bodyGroesseVorgetaeuscht = false;
+}
+
 function clearDesktopCookies() {
   document.cookie = 'tessera_desktop=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/';
   document.cookie = 'tessera_desktop_client=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/';
@@ -100,15 +121,21 @@ afterEach(() => {
   cleanup();
   clearErrorBuffer();
   clearDesktopCookies();
+  restoreBodyGroesse();
   vi.unstubAllGlobals();
 });
 
 describe('BugReportButton (quick-260914-m97)', () => {
   it('Test 1: Bild VOR dem Dialog — toPng laeuft ohne offenen Dialog, mit document.body, pixelRatio 1, skipFonts, 1600-px-Kante; danach Dialog mit Vorschau, Haekchen an, Textfeld leer', async () => {
-    Object.defineProperty(document.body, 'scrollWidth', { value: 3200, configurable: true });
-    Object.defineProperty(document.body, 'scrollHeight', { value: 1000, configurable: true });
+    stubBodyGroesse(3200, 1000);
+    // Kein `expect` INNERHALB der Attrappe: ein Fehler daraus landet mitten im
+    // `await` der Komponente und wird von `captureScreenshot` verschluckt
+    // (`catch` liefert `null`) — der Test waere dann an ganz anderer Stelle
+    // mit irrefuehrender Meldung durchgefallen. Also nur festhalten, unten
+    // pruefen (quick-260921-ldf).
+    let dialogWaehrendDerAufnahme: unknown = 'toPng wurde nicht aufgerufen';
     mockToPng.mockImplementation(async () => {
-      expect(screen.queryByRole('dialog')).toBeNull();
+      dialogWaehrendDerAufnahme = screen.queryByRole('dialog');
       return DATA_URL;
     });
     const user = userEvent.setup();
@@ -117,6 +144,7 @@ describe('BugReportButton (quick-260914-m97)', () => {
     const dialog = await openDialog(user);
 
     expect(mockToPng).toHaveBeenCalledTimes(1);
+    expect(dialogWaehrendDerAufnahme).toBeNull();
     const [node, opts] = mockToPng.mock.calls[0] as [unknown, Record<string, unknown>];
     expect(node).toBe(document.body);
     expect(opts).toMatchObject({ pixelRatio: 1, skipFonts: true, canvasWidth: 1600, canvasHeight: 500 });
@@ -321,6 +349,82 @@ describe('BugReportButton (quick-260914-m97)', () => {
     expect(body.get('clientVersion')).toBe('');
     expect(body.get('clientCommit')).toBe('');
   });
+
+  /**
+   * Test 14/15 (quick-260921-ldf) sind der Nachweis fuer die Ursache des
+   * Wackeltests aus CI-Lauf 395. Der Dialog zog seinen Anfangszustand frueher
+   * per `useEffect` nach; React schrieb deshalb bei JEDEM Oeffnen zuerst einen
+   * falschen DOM-Zustand fest und korrigierte ihn erst einen Commit spaeter.
+   * Gemessen hielt der falsche Zustand zwei volle Makrotask-Runden — lange
+   * genug, dass der Browser ihn zeichnen konnte und der Test ihn gelegentlich
+   * sah. Die beiden Tests beobachten jeden Commit und dulden keinen einzigen
+   * falschen.
+   */
+  function protokolliereCommits(): { commits: string[]; stop: () => void } {
+    const commits: string[] = [];
+    const obs = new MutationObserver(() => {
+      const dialog = document.querySelector('[role="dialog"]');
+      if (!dialog) return;
+      const bild = dialog.querySelector('img');
+      const box = document.getElementById('bug-report-attach') as HTMLInputElement | null;
+      const feld = document.getElementById('bug-report-description') as HTMLTextAreaElement | null;
+      const danke = dialog.textContent?.includes(T.sent) ?? false;
+      commits.push(
+        `bild=${bild ? 'ja' : 'nein'} haekchen=${box ? (box.checked ? 'an' : 'aus') : '-'} ` +
+          `gesperrt=${box ? box.disabled : '-'} text="${feld?.value ?? ''}" danke=${danke}`,
+      );
+    });
+    obs.observe(document.body, { childList: true, subtree: true, attributes: true });
+    return { commits, stop: () => obs.disconnect() };
+  }
+
+  it('Test 14 (quick-260921-ldf): kein falscher Zwischenzustand — in KEINEM Commit steht das Vorschaubild mit ausgeschaltetem Haekchen', async () => {
+    const { commits, stop } = protokolliereCommits();
+    try {
+      const user = userEvent.setup();
+      await renderButton();
+      await openDialog(user);
+    } finally {
+      stop();
+    }
+
+    expect(commits.length).toBeGreaterThan(0);
+    const falsche = commits.filter((c) => c.includes('bild=ja') && c.includes('haekchen=aus') && c.includes('gesperrt=false'));
+    expect(falsche).toEqual([]);
+    // Und der allererste Commit mit Dialog ist schon der richtige.
+    expect(commits[0]).toContain('bild=ja');
+    expect(commits[0]).toContain('haekchen=an');
+  });
+
+  it('Test 15 (quick-260921-ldf): erneutes Oeffnen startet frisch — kein alter Dankestext, kein alter Text, Haekchen wieder an', async () => {
+    mockFetch.mockResolvedValue(jsonResponse(200, { sent: true }));
+    const user = userEvent.setup();
+    await renderButton();
+
+    // Erstes Oeffnen: Haekchen abwaehlen, Text tippen, senden, schliessen.
+    await openDialog(user);
+    await user.click(screen.getByRole('checkbox', { name: T.attachScreenshot }));
+    await user.type(screen.getByLabelText(T.descriptionLabel), 'alter Text');
+    await user.click(screen.getByRole('button', { name: T.send }));
+    await screen.findByText(T.sent);
+    await user.click(screen.getByRole('button', { name: T.close }));
+    await waitFor(() => expect(screen.queryByRole('dialog')).toBeNull());
+
+    // Zweites Oeffnen: jeder Commit muss frisch sein.
+    const { commits, stop } = protokolliereCommits();
+    try {
+      await openDialog(user);
+    } finally {
+      stop();
+    }
+
+    expect(commits.length).toBeGreaterThan(0);
+    expect(commits.filter((c) => c.includes('danke=true'))).toEqual([]);
+    expect(commits.filter((c) => c.includes('text="alter Text"'))).toEqual([]);
+    expect(commits.filter((c) => c.includes('bild=ja') && c.includes('haekchen=aus') && c.includes('gesperrt=false'))).toEqual([]);
+    expect(screen.getByRole('checkbox', { name: T.attachScreenshot })).toBeChecked();
+    expect(screen.getByLabelText(T.descriptionLabel)).toHaveValue('');
+  });
 });
 
 describe('computeCaptureSize (quick-260914-m97, reine Funktion)', () => {

apps/web/src/components/bug-report/bug-report-button.tsx

@@ -66,7 +66,11 @@ export function BugReportButton() {
           <path d="M17.2 17c2.1.1 3.8 1.9 3.8 4" />
         </svg>
       </button>
-      <BugReportDialog open={open} screenshot={screenshot} isAdmin={isAdmin} onClose={() => setOpen(false)} />
+      {/* Nur eingehaengt, solange offen (quick-260921-ldf): so startet jedes
+          Oeffnen mit frischem Zustand — Haekchen, Text und Status stimmen
+          schon im ersten Commit, statt einen Commit spaeter nachgezogen zu
+          werden. */}
+      {open && <BugReportDialog screenshot={screenshot} isAdmin={isAdmin} onClose={() => setOpen(false)} />}
     </>
   );
 }

apps/web/src/components/bug-report/bug-report-dialog.tsx

@@ -13,9 +13,13 @@ import { formatErrorsForReport } from '@/lib/error-buffer';
  * `marketplace/components/ActivationDialog.tsx` (Overlay, `role="dialog"`,
  * Escape, Fokus). Bekommt das bereits aufgenommene Bild als Data-URL —
  * die Aufnahme passiert im Knopf, BEVOR dieser Dialog erscheint.
+ *
+ * Der Dialog wird nur eingehaengt, solange er offen ist (quick-260921-ldf):
+ * jedes Oeffnen ist ein frischer Mount, damit gilt der Anfangszustand schon
+ * im ERSTEN Commit. Vorher zog ein Effekt den Zustand erst einen Commit
+ * spaeter nach — dazwischen stand sichtbar "Bild da, Haekchen aus" im DOM.
  */
 interface BugReportDialogProps {
-  open: boolean;
   screenshot: string | null;
   isAdmin: boolean;
   onClose: () => void;
@@ -23,35 +27,29 @@ interface BugReportDialogProps {
 
 type Status = 'ready' | 'sending' | 'sent' | 'failed';
 
-export function BugReportDialog({ open, screenshot, isAdmin, onClose }: BugReportDialogProps) {
+export function BugReportDialog({ screenshot, isAdmin, onClose }: BugReportDialogProps) {
   const t = useTranslations('bugReport');
   const textareaRef = useRef<HTMLTextAreaElement>(null);
   const [status, setStatus] = useState<Status>('ready');
   const [failedStatus, setFailedStatus] = useState(0);
   const [description, setDescription] = useState('');
-  const [attach, setAttach] = useState(screenshot !== null);
+  // Das Haekchen wird beim Rendern aus `screenshot` abgeleitet, nicht per
+  // Effekt nachgezogen: gibt es ein Bild, ist es an. `attachChoice` haelt
+  // allein die bewusste Abwahl des Nutzers.
+  const [attachChoice, setAttachChoice] = useState<boolean | null>(null);
+  const attach = screenshot !== null && (attachChoice ?? true);
 
-  // Bei jedem Oeffnen frisch beginnen.
   useEffect(() => {
-    if (open) {
-      setStatus('ready');
-      setFailedStatus(0);
-      setDescription('');
-      setAttach(screenshot !== null);
     textareaRef.current?.focus();
-    }
-  }, [open, screenshot]);
+  }, []);
 
   useEffect(() => {
-    if (!open) return;
     const handler = (e: KeyboardEvent) => {
       if (e.key === 'Escape' && status !== 'sending') onClose();
     };
     document.addEventListener('keydown', handler);
     return () => document.removeEventListener('keydown', handler);
-  }, [open, status, onClose]);
-
-  if (!open) return null;
+  }, [status, onClose]);
 
   const handleSend = async () => {
     setStatus('sending');
@@ -144,7 +142,7 @@ export function BugReportDialog({ open, screenshot, isAdmin, onClose }: BugRepor
                 className="h-4 w-4"
                 checked={attach}
                 disabled={screenshot === null || busy}
-                onChange={(e) => setAttach(e.target.checked)}
+                onChange={(e) => setAttachChoice(e.target.checked)}
               />
               <label htmlFor="bug-report-attach" className="text-sm text-foreground">
                 {t('attachScreenshot')}