Erprobungshinweis: erst wenn das Fenster steht, und nach vorn geholt

Sein Befund: "die software haengt nun am dialog popup" - und gleich darauf:
"haengen tut er nicht, nur deine pruefung; wenn ich auf aktiv druecke, geht es".

Zwei getrennte Fehler, beide meine:

1. Der Hinweis lief an after(0). Da ist das Hauptfenster noch nicht gezeichnet -
   ein modaler Dialog daran wirkt eingefroren. Eine feste Wartezeit (150 ms) war
   aber auch falsch: die erreicht ein Pruefstand nie, der keine Ereignisschleife
   dreht, und pruef_api lief danach in die Zeitgrenze. Jetzt after_idle: laeuft,
   sobald Tk nichts mehr zu zeichnen hat - fuer den Nutzer nach dem Zeichnen,
   fuer den Pruefstand beim ersten update().

2. Der Dialog kam nicht nach vorn. Ein Hinweis, den man erst suchen muss, taugt
   nichts. theme.py holt das Meldungsfenster jetzt nach vorn und nimmt den
   Tastaturfokus (lift, kurz topmost, focus_force).

In der Aufgabenliste vermerkt: Updater als Starter (Schritt 4, mit den zwei
fehlenden Voraussetzungen Versionsnummer und Sichtbarkeit der Repositories),
Pcore-Design im Steuerrechnungstool (Schritt 5), und der ALTFEHLER in
pruef_wache - schon vor den heutigen Arbeiten rot, die Statuszeile wird vom
Ergebnis des Einlesens ueberschrieben.

Alle 17 Pruefstaende des Rechnungstools gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V4t48uxDok5rJXhC9bX1Ax

AUFGABE_BEWEISKETTE_PRUEFBAR.md

@@ -65,6 +65,67 @@ Betriebsprüfung. Beide bleiben nebeneinander bestehen.
 
 ---
 
+## Schritt 4 — Updater als Starter ⬜ OFFEN
+
+Sein Bild (06.09.2026): *„der updater schaut beim starten erst: ist auf dem git link eine neue
+version mit exe? wenn ja, erst laden, ersetzen und dann starten."* Dazu: *„einmal prüfen auf
+vollständigkeit."*
+
+**Warum das der richtige Aufbau ist:** Der Updater ist das, was der Nutzer startet. Er läuft
+**bevor** das Programm läuft — damit gibt es das übliche Problem gar nicht, dass eine laufende EXE
+sich nicht selbst ersetzen kann.
+
+**Ablauf:**
+1. Beim Start die Release-Angaben vom Repository holen.
+2. Ist die dortige Version neuer als die installierte → Datei in einen **Zwischenordner** laden.
+3. **Vollständigkeit prüfen** — Größe und Prüfsumme gegen die Angabe des Releases. Erst wenn beides
+   stimmt, wird ersetzt. Ein halb geladener Download darf die Installation nie erreichen.
+4. Alte Fassung als **Rückfallebene** behalten; scheitert der Start, zurücktauschen.
+5. Programm starten.
+
+**⚠️ Zwei Voraussetzungen fehlen noch:**
+- **Es gibt keine Versionsnummer im Programm.** Ohne die kann kein Updater vergleichen. Muss zuerst
+  eingeführt werden — an einer Stelle, aus der auch die EXE-Metadaten und der Info-Dialog lesen.
+- **Sind die Repositories öffentlich?** Wenn nicht, braucht der Updater einen Zugangstoken — und
+  ein Token, das in einer verteilten EXE steckt, ist kein Geheimnis mehr. Dann müssten die Releases
+  öffentlich sein oder über eine andere Stelle ausgeliefert werden.
+
+**Und Andreas' Ansage zu den Releases:** *„die alten als experimental taggen, nicht als stabil —
+weil die sind nicht stabil."*
+
+---
+
+## Schritt 5 — Pcore-Design im Steuerrechnungstool ⬜ OFFEN
+
+Sein Wunsch: *„aber bitte mit unserm theme style."*
+
+**Befund:** Das Steuerrechnungstool hat **kein `theme.py`**. Es benutzt nackte ttk-Widgets mit
+Segoe UI. Das Rechnungstool hat das ganze Pcore/Ravokk-Design — Farben, Roboto, Glass-Buttons,
+eigene Meldungsfenster (`MeldungMixin`), hell und dunkel.
+
+**Zu tun:** `theme.py` herüberziehen und die Oberfläche darauf umstellen. Das ist ein eigener Bau,
+kein Nebenbei — Menüs, Tabellen, Dialoge, Statusleiste. Vorher planen.
+
+---
+
+## ⚠️ Gefundener Altfehler — `pruef_wache` (Steuerrechnungstool) ⬜ OFFEN
+
+**Nicht von den Arbeiten am 06.09.2026 verursacht** — bei der Ausgangsmessung vor dem Umbau bereits
+rot, nur mit anderem Text.
+
+`pruef_wache.py` erwartet nach einem Push des Rechnungstools in der Statuszeile den Hinweis
+**„Rechnungstool meldet"**. Tatsächlich steht dort das Ergebnis des anschließenden Einlesens
+(`0 neu, 0 aktualisiert, 1 unverändert`; bei der Ausgangsmessung: `Nummernbuch: 1 Nummern
+eingetragen`). Das Einlesen **überschreibt die Meldung**, bevor der Nutzer sie lesen kann.
+
+**Zu klären:** Ist das ein Fehler im Programm (die Meldung soll stehen bleiben, das Ergebnis
+danebengehören) oder eine veraltete Erwartung im Prüfstand? Nicht nebenbei entscheiden — die
+Statuszeile ist das Einzige, was dem Nutzer sagt, dass die andere Anwendung etwas gemeldet hat.
+
+Folgefehler derselben Stelle: „dann kommt keine Meldung dazu".
+
+---
+
 ## Reihenfolge
 
 Schritt 2 zuerst — er schließt eine Lücke in dem, was gerade gebaut wurde, und ist klein.