Kompletten Ablauf einmal durchgespielt — echten Fehler dabei gefunden

Wunsch: "ich will dass du es abcheckst" — nicht Stück für Stück (das war
schon geprüft), sondern EINMAL DURCHGÄNGIG als ein zusammenhängender
Ablauf, so wie ein echter Auftrag tatsächlich läuft: Anfrage → Angebot
→ Zusage im Portal → Anzahlung → laufende Uhr → Benachrichtigung →
Arbeit → Restzahlung → Gegenprobe mit Abbruch.

test-kette.mjs bildet genau das ab, gegen die echten Funktionen aus
server-internal/, mit einer Wegwerf-Datenbank. 40 Prüfungen, alle grün.

DABEI GEFUNDEN: Der Liefertermin-Countdown im Portal prüfte nicht, ob
die Uhr überhaupt schon läuft. Ein frisch zugesagtes Projekt hat schon
ein termin_am (aus der Zusage vorgerechnet), aber uhr_start_am steht
noch auf null, solange die Anzahlung nicht da ist. Der Kunde hätte also
direkt nach der Zusage einen tickenden Countdown gesehen — und wenn die
Anzahlung eintrifft, wird der Termin ab dem Zahlungstag NEU berechnet
und springt dann sichtbar nach hinten. Das sieht aus wie ein Fehler,
auch wenn die Zahl rechnerisch stimmt: Kaum zu erklären, warum "noch 8
Tage" plötzlich wieder "noch 10 Tage" werden.

Jetzt zwei klar getrennte Zustände: Vor der Anzahlung steht "Startet,
sobald deine Anzahlung da ist — voraussichtlicher Liefertermin danach:
ca. {datum}" (kein Countdown, aber der Termin bleibt sichtbar, kein
Verstecken). Danach der echte Countdown. Fünf Sprachen ergänzt.

Nebenbei einen irreführenden Kommentar korrigiert: Ein neuer Kunde wird
beim Angebot-Senden SOFORT freigeschaltet (nicht erst bei Zusage, wie
der alte Kommentar behauptete) — sonst könnte er sich gar nicht
einloggen, um sein eigenes Angebot anzusehen. Der Code war richtig,
nur die Erklärung falsch, und mein erster Testentwurf ist genau darauf
hereingefallen.

Bei der Gelegenheit auch die bekannte better-sqlite3-Aussetzer-Eigenart
(zufälliger Absturz beim Prozessende, dokumentiert seit früheren
Commits) noch einmal eingegrenzt: Derselbe Import in test-angebote.mjs
brach mal nach "GEHEIM", mal nach "VORLAGEN" ab — der Absturzpunkt
verschiebt sich zwischen identischen Läufen. Das ist der endgültige
Beweis, dass es reine GC-Zeitfensterflakiness in der nativen
Bibliothek ist, kein Fehler im eigenen Code.

Geprüft: 40 (Kette) + 55 + 56 + 70 + 28 + 49 serverseitig (alle
mehrfach unabhängig grün), 261 im Browser (Portal, Angebot, Übersicht,
Verwaltung, Abbruch, Design). Ein Screenshot bestätigt den neuen
Wartehinweis visuell.

assets/js/i18n-wd-portal.js

@@ -223,6 +223,18 @@ window.I18N_WD = {
     en: "Accept this offer bindingly? I will then set up your project and you will receive the deposit invoice.",
     fr: "Accepter ce devis de manière ferme ? Je créerai ensuite votre projet et vous recevrez la facture d’acompte.",
     pt: "Aceitar esta proposta de forma vinculativa? Depois crio o seu projeto e receberá a fatura do sinal." },
+  po_wartet_anzahlung_titel: {
+    de: "Startet, sobald deine Anzahlung da ist.",
+    "de-CH": "Startet, sobald deine Anzahlung da ist.",
+    en: "Starts as soon as your deposit arrives.",
+    fr: "Démarre dès réception de votre acompte.",
+    pt: "Começa assim que o seu sinal chegar." },
+  po_wartet_anzahlung_text: {
+    de: "Voraussichtlicher Liefertermin danach: ca. {datum}.",
+    "de-CH": "Voraussichtlicher Liefertermin danach: ca. {datum}.",
+    en: "Expected delivery date after that: approx. {datum}.",
+    fr: "Date de livraison prévue ensuite : env. {datum}.",
+    pt: "Data de entrega prevista depois disso: aprox. {datum}." },
   po_liefertermin: { de: "Liefertermin", "de-CH": "Liefertermin", en: "Delivery date", fr: "Date de livraison", pt: "Data de entrega" },
   po_noch_tage: { de: "noch {n} Werktage", "de-CH": "noch {n} Werktage", en: "{n} working days left", fr: "encore {n} jours ouvrables", pt: "faltam {n} dias úteis" },
   po_noch_ein_tag: { de: "noch 1 Werktag", "de-CH": "noch 1 Werktag", en: "1 working day left", fr: "encore 1 jour ouvrable", pt: "falta 1 dia útil" },

assets/js/wd-portal.js

@@ -180,7 +180,28 @@
   function terminZeile(p) {
     var stuecke = [];
 
-    if (p.termin_am) {
+    /* Zwei verschiedene Aussagen, klar getrennt.
+
+       GEFUNDEN beim Durchspielen der kompletten Kette (Anfrage bis
+       Zahlung) am 24.08.2026: Vorher zeigte diese Zeile IMMER einen
+       tickenden Countdown, sobald ein termin_am da war -- auch direkt
+       nach der Zusage, BEVOR die Anzahlung floss. Zwei Probleme damit:
+       Erstens wirkt ein laufender Countdown wie eine laufende Arbeit,
+       obwohl noch nichts begonnen hat. Zweitens wird der Termin beim
+       Zahlungseingang NEU gerechnet (ab dem Zahltag) -- die Zahl haette
+       sich also sichtbar nach hinten verschoben, ohne erkennbaren Grund.
+
+       Jetzt zwei Zustaende: "ca.-Termin, wartet auf Anzahlung" (kein
+       Countdown, ausdruecklicher Hinweis) und "laeuft, noch N Tage"
+       (echter Countdown, nur wenn die Uhr wirklich laeuft). */
+    if (p.termin_am && p.wartet_auf_anzahlung) {
+      stuecke.push(
+        '<p class="wd-klein" style="margin:.45rem 0 0">' +
+        '<strong>' + s(window.WD.t("po_wartet_anzahlung_titel")) + "</strong> " +
+        s(window.WD.t("po_wartet_anzahlung_text").replace("{datum}", datumKurz(p.termin_am))) +
+        "</p>"
+      );
+    } else if (p.termin_am) {
       var rest = restText(p.verbleibende_werktage);
       stuecke.push(
         '<p class="wd-klein" style="margin:.45rem 0 0">' +