2 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGit	521f0d5a80	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.	2026-08-24 16:54:35 +02:00
DogFatherGitandClaude Opus 5	cea265eb8c	Angebote: der Kunde sagt mit einem Klick zu ... DER LEITGEDANKE: SO WENIG TIPPEN WIE MOEGLICH Niemand schreibt hier den Leistungsumfang. Er entsteht aus der Aufgabenvorlage des Pakets -- denselben 92 Punkten, nach denen spaeter gearbeitet wird. Der Nebeneffekt ist wichtiger als die gesparte Tipparbeit: Was im Angebot steht, IST die Arbeitsliste. Ein von Hand geschriebenes Angebot und eine getrennt gepflegte Aufgabenliste laufen unweigerlich auseinander -- und dann steht im Angebot etwas, das niemand abarbeitet. Zu tun bleibt: Paket waehlen, Preis bestaetigen. Beides ist vorbelegt, Laufzeit und Ablaufdatum werden gerechnet. DER WORTLAUT WIRD BEIM ABSENDEN EINGEFROREN Ein angenommenes Angebot ist ein Vertrag. Bei einem Streit zaehlt, WAS dem Kunden gezeigt wurde, als er zusagte. Wuerde der Text bei jeder Ansicht neu aus den Vorlagen erzeugt, staende nach der naechsten Vorlagenaenderung etwas anderes da als damals. Die Zusage wird mit Zeitpunkt und (gehashter) Herkunft belegt -- die Beweislast liegt beim Unternehmer. WAS AUTOMATISCH PASSIERT Angebot raus -> Anfrage steht auf 'angebot' (der Wunsch: 'wenn ich ein angebot rausschicke soll der automatisch das erkennen'). Zusage -> Projekt angelegt, Aufgabenliste eingesetzt, Anzahlung als offene Rechnung erzeugt, Anfrage auf 'angenommen', Benachrichtigung an mich. Die UHR startet dabei NICHT. Sie startet erst mit dem Zahlungseingang -- das ist die Regel aus dem vorigen Schritt, und sie gilt auch dann, wenn der Kunde selbst zugesagt hat. Genau dieser Punkt wird ausdruecklich geprueft: Es fuehlt sich richtig an, mit der Zusage loszulegen. ZWEI FEHLER IN DER GELDANZEIGE GEFUNDEN Beide fielen erst auf, als das erste Angebot ueber tausend Euro entstand -- alle frueheren Testbetraege lagen darunter: - Kein Tausenderpunkt: 1490 Euro erschienen als '1490,00 €'. - Das Minuszeichen ging verloren: Math.trunc(-0.5) ergibt -0, und -0 schreibt sich als '0'. Eine ERSTATTUNG von 50 Cent erschien damit als '0,50 €' -- also wie eine Forderung. Ausgerechnet beim Abbruch mit Rueckzahlung waere das der falsche Ort fuer einen Anzeigefehler. Bewusst von Hand statt ueber Intl.NumberFormat: Die Ausgabe muss auf dem Server und im Browser zeichengleich sein -- ein Betrag, der in der Verwaltung anders aussieht als im Portal, saet Zweifel an der Zahl. Geprueft: 56 zu den Angeboten, 53 zur Automatik (inkl. der neun Geldpruefungen), 70 zur Annahme, 28 zur Suche -- alle gegen eine echte Datenbank. Darunter: zweiter Klick legt nichts doppelt an, abgelaufene Angebote lassen sich nicht mehr annehmen (ein Angebot, das man sieht aber nicht annehmen kann, waere eine Falle), ein fremder Kunde erfaehrt nicht einmal, dass ein Angebot existiert. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-24 12:14:27 +02:00