[oe5sos]

beimZiehenWirdDerRahmenSICHTBAR war auf main rot (Linux-Shard 3/4, 1 von 304
— derselbe Fall und derselbe Shard wie am 2026-10-20). Das Programm hat dabei
vollkommen richtig gearbeitet.

Die Ursache stand im vollen Protokoll, nicht in den FAIL-Zeilen

QINFO : … Schutzrahmen: 1 schwebende Fenster lagen auf einer Bedienleiste
        und wurden heruntergeschoben
FAIL! : beimZiehenWirdDerRahmenSICHTBAR() … (der Rahmen bleibt beim Ziehen
        unsichtbar)

Nach dem Aufbau setzt MainWindow zwei Nachläufe an (MainWindow.cpp,
„Zwei Nachläufe"): singleShot(0) und singleShot(500), beide rufen
schwebendeAusDemSchutzrahmenHolen(). Auf dem lastigen Läufer kam der zweite
erst mitten in der Messung — er holte den eben platzierten Schweber von der
Sperrzone weg. Danach berührte nichts mehr etwas, also schwieg meldeZug() zu
Recht.

Drei Änderungen, alle im Prüfstand

• warteBisDasHauptfensterSteht() nach dem Muster von
  warteBisDerRahmenSteht() aus tst_side_area_integration.cpp (Zwei Fensterprüfstände: auf Ruhe warten, Grundlage frisch erzwingen #451):
  Mindestfrist über die 500 ms hinaus, danach auf Ruhe warten — drei gleiche
  Messungen der Fenstergeometrie, nicht eine. Auf den Zustand warten, nicht
  auf die Uhr.
• Das processEvents() zwischen move() und meldeZug() ist weg. Genau in
  dieser Lücke lief der Nachlauf. meldeZug() liest frameGeometry() direkt.
• Sprechende Meldungen. Fällt der Fall doch, sagt er jetzt, wo das Fenster
  liegt und dass ein Nachlauf es geholt haben kann. Die alte Meldung hat mich
  zuerst auf die falsche Spur geführt.

Neuer Prüffall für eine ungedeckte Wache

einePlatzierungLoestDenHinweisNICHTAus: die Wache
if (s_eigeneBewegungen > 0) { return; } in meldeZug() war nirgends
festgenagelt — in keinem der vier Prüffälle, die EigeneBewegung überhaupt
nennen. Darum konnte ich sie zuerst für die Ursache halten; nichts schloss sie
aus. Jetzt tut es etwas, und zwar in beide Richtungen: eine Platzierung löst den
Hinweis nicht aus, ein echter Zug danach aber doch.

Zwei Gegenproben

Ein lokal grüner Lauf beweist hier nichts — der Fall war vor der Behebung lokal
grün und auf dem Läufer rot. Also die Lage gezielt hergestellt:

1. Nachlauf mitten in die Messung (mw.schwebendeAusDemSchutzrahmenHolen()
   zwischen move() und der Prüfung) → rot, mit derselben Protokollzeile wie
   in der CI und der neuen Meldung
   die Lage kam nicht an: 42,100 304x124 trifft die Sperrzone nicht.
2. Die Wache aus meldeZug() entfernt → einePlatzierungLoestDenHinweis NICHTAus wird rot („der Hinweis blinkt beim PLATZIEREN").

ctest -R "^tst_schutzrahmen$" grün (6,2 s), 24 Prüffälle.

🤖 Generated with Claude Code