diff --git a/AUFGABE_BEWEISKETTE_PRUEFBAR.md b/AUFGABE_BEWEISKETTE_PRUEFBAR.md
index 7b0a57b..7443f0c 100644
--- a/AUFGABE_BEWEISKETTE_PRUEFBAR.md
+++ b/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.
diff --git a/app.py b/app.py
index a6a644c..b833b73 100644
--- a/app.py
+++ b/app.py
@@ -118,10 +118,11 @@ class RechnungsApp(ThemeMixin, MeldungMixin, KorrekturMixin, EinstellungenMixin,
         # es morgen ohne berichtigte Rechnung im Ordner und keiner weiss warum.
         self.protocol("WM_DELETE_WINDOW", self._beenden)
 
-        # NICHTS laeuft an, bevor der Erprobungshinweis bestaetigt ist. Wer ihn
-        # ablehnt, soll gar nicht erst arbeiten koennen - und es soll auch kein
-        # halb gestartetes Programm hinter dem Fenster stehenbleiben.
-        self.after(0, self._hinweis_pruefen)
+        # after_idle statt after(0): laeuft, sobald Tk nichts mehr zu zeichnen hat -
+        # also nachdem das Hauptfenster steht. Bei after(0) haengt der modale Dialog
+        # an einem noch ungezeichneten Fenster und wirkt wie eingefroren; eine feste
+        # Wartezeit dagegen erreicht ein Pruefstand nie, der keine Schleife dreht.
+        self.after_idle(self._hinweis_pruefen)
 
 
     # ---------------------------------------------------------------- Menue
@@ -650,6 +651,7 @@ class RechnungsApp(ThemeMixin, MeldungMixin, KorrekturMixin, EinstellungenMixin,
         stuenden beim Ablehnen noch Timer in der Warteschlange, die auf ein
         Fenster zugreifen, das es nicht mehr gibt.
         """
+        self.update_idletasks()   # Fenster fertig zeichnen lassen
         if not hinweis.angenommen(self.cfg):
             print(f"[hinweis] Kenntnisnahme noch offen (Fassung {hinweis.FASSUNG})")
             if not self.frage(hinweis.TITEL, hinweis.text("rechnungstool"),
diff --git a/theme.py b/theme.py
index 99d35d8..ce12a81 100644
--- a/theme.py
+++ b/theme.py
@@ -473,6 +473,13 @@ class MeldungMixin:
         x = self.winfo_rootx() + max(0, (self.winfo_width() - d.winfo_reqwidth()) // 2)
         y = self.winfo_rooty() + 140
         d.geometry(f"+{max(0, x)}+{max(0, y)}")
+        # Nach vorn holen und den Tastaturfokus nehmen. Ohne das kann der Dialog
+        # beim Start hinter dem Hauptfenster liegen - der Nutzer sieht nur ein
+        # Fenster, das nicht reagiert, und haelt es fuer haengen geblieben.
+        d.lift()
+        d.attributes("-topmost", True)
+        d.after(100, lambda: d.attributes("-topmost", False))
+        d.focus_force()
         d.grab_set()
         d.focus_set()
         self.wait_window(d)