Commit Graph
9 Commits
Author SHA1 Message Date
ClaudeandClaude Sonnet 5.5 6eb4dd3c51 Hustler-Stufe: Keller begehbar ab Stufe 3, Bot-Leads abrufbar erst ab Stufe 6
Die Stufen-Sperre trennt jetzt zwei Dinge: KELLER_BEGEHBAR_AB = 3 (Keller-Etage als Link,
?tab=botleads gueltig, Spur-Links in den Keller) und BOTLEADS_AB = 6 (Abruf von GET /botleads).
kellerOffen/STUFE_KELLER entfallen, dafuer kellerBegehbar() und botleadsAbrufbar().
workersApi.botleads bleibt unter Stufe 6 hart gesperrt, der Text heisst nun
BOTLEADS_GESPERRT_TEXT. Die Keller-Ansicht selbst (leeres Register ohne Abruf) folgt im
naechsten Commit.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-22 12:21:59 +00:00
ClaudeandClaude Sonnet 5.5 32f4f1d941 Hustler-Stufe: Keller und Bot-Leads erst ab Stufe 6 (Seite, Keller-Etage, Spur-Links, Abruf von /botleads)
WorkersPage: ?tab=botleads (auch mit &bot=) und unbekannte Werte fallen unterhalb von Stufe 6 auf das Hochhaus zurück, BotLeadList wird nie eingehängt; die Weiterleitungen /leads und /workers bleiben.
HochhausWelt: die Keller-Etage ist dann ein Knopf wie jede andere (zoomt heran) statt eines Links; Arne bleibt klickbar, die Zahl Bot-Leads in der Kopfzeile bleibt Text.
HustlerDialog: Spur-Links in den Keller bleiben Text. workersApi.botleads ruft unterhalb von Stufe 6 nichts ab (kein JWT, keine Anfrage), sondern liefert 404 mit deutschem Satz.
Bestehende Keller-Tests laufen ausdrücklich auf Stufe 6; neue Tests prüfen Stufe 1, 3 und 5 (gesperrt) und 6 bis 9 (offen).

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-22 10:36:52 +00:00
ClaudeandClaude Sonnet 5.5 41ae7ffd3f Endprüfung Nachrunde R7: Test der Zeitgrenze (D14) für reply, approve-preview und start-build wiederhergestellt
Der Commit 1536a3b hatte den Test „reply, approve-preview und start-build warten länger als die übrigen
Pult-Aktionen“ gelöscht. Der neue Test prüft gegen den heutigen Code (ACTION_TIMEOUT_MS 65 s,
REQUEST_TIMEOUT_MS 20 s, Optionen timeoutMs / actionTimeoutMs) mit den Uhren von node:test statt echter
Wartezeit: keine Abhängigkeit von der Last, Grenzen auf die Millisekunde (eine Millisekunde vor der Frist
läuft der Abruf, mit ihr endet er). Die drei langsamen Aktionen nehmen eine Antwort zwischen kurzer und langer
Frist an, claim/sent/discard/done/paste und das Lesen enden mit der kurzen Frist (DOWN_TEXT, status 0, Signal
abgebrochen), ein hängender Abruf endet nach der langen Frist. Derselbe Ablauf mit Standard- und mit
eingespeisten Fristen; ein zweiter Test pinnt, dass auch der Wiederholungsversuch nach einer 401 die Frist
der Aktion behält.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-18 23:54:10 +00:00
ClaudeandClaude Sonnet 5.5 1536a3bbc1 Workers P4 Endprüfung W1: 502/504 beim Warten heißen bei reply, approve-preview und start-build „Kann gesendet sein“
Die Unsicherheits-Meldung (D14) galt nur für status 0. Eine Fehlerseite des Proxys (502, 504) zeigte
„Der Hustler-Dienst ist gerade nicht erreichbar.“, obwohl der Dienst weiterarbeitet und die Mail schon
hinausgegangen sein kann. workersApi.js exportiert UNCERTAIN_STATUS = [0, 502, 504]; actionErrorText
prüft ihn (503, 429, 4xx und 500 bleiben unverändert, ebenso ein Satz des Dienstes unter 502).
ACTION_TIMEOUT_MS steigt auf 65 s, damit der Client nicht gleichauf mit dem proxy_read_timeout (60 s)
läuft und ein 504 zuerst ankommt. Tests über createWorkersApi mit Fehlerseiten für alle acht Aktionen.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-18 23:07:38 +00:00
ClaudeandClaude Sonnet 5.5 533091c333 Workers P4: Pult – als Mensch antworten, Vorschau freigeben, Antwort des Kunden einfügen
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-18 22:08:48 +00:00
ClaudeandClaude Sonnet 5.5 2b2b45a0c7 Workers P3-Endprüfung W1: createJWT sperrt nur bei echter Ablehnung durch Appwrite
Nur ein HTTP-Code ab 400 von Appwrite startet die 2-Minuten-Sperre. Übertragungsfehler
(TypeError, SDK-Fehler mit code 0, Fehler ohne Code), auch wenn sie erst nach der
Zeitgrenze eintreffen, geben die Dienst-Meldung (status 0) und sperren nichts: nach dem
Aufwachen aus dem Ruhezustand erholt sich das Hochhaus mit dem nächsten Takt. Eine späte
echte Ablehnung (etwa 429) sperrt weiter.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-18 10:40:10 +00:00
ClaudeandClaude Sonnet 5.5 777d5272bf Workers P3: Nachträge aus der P2-Endprüfung (Kennungen, JWT-Sperre, Abmelden, Bestätigung)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-18 09:36:00 +00:00
ClaudeandClaude Sonnet 5.5 9ebc562c83 Workers P2: Zeitgrenze je Abruf und Sperre für frische JWTs nach einer 401-Folge
Endprüfung P2. Ein Abruf auf toter Verbindung (Rechner im Ruhezustand, Netzwechsel) blieb offen, und die
Feed-Schleifen laufen mit einem Abruf je Schleife: die Seite stand still und zeigte veraltete Daten als aktuell.
createWorkersApi bricht jetzt jeden Versuch (JWT holen, senden, Antwort lesen) nach 20 s mit "Der Hustler-Dienst ist
gerade nicht erreichbar." (status 0) ab, auch wenn fetch oder createJWT das Signal nicht beachten.

Außerdem erzwang jede 401-Antwort ein frisches createJWT, bei dauerhaftem 401 etwa 16 bis 20 Mal je Minute und Tab.
Appwrite begrenzt createJWT je Nutzer; das Limit hätte auch Serverpuls, Finanzen und Vorschauen gesperrt. Nach einer
401-Folge (frisches JWT wird ebenfalls abgelehnt oder lässt sich nicht erzeugen) gibt es 2 Minuten lang kein frisches
JWT mehr, die Meldung "Anmeldung abgelaufen" bleibt; Erfolg hebt die Sperre auf.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-18 05:34:51 +00:00
ClaudeandClaude Sonnet 5.5 97fdfbfcf0 Workers P2: API-Client mit deutschen Fehlertexten
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-18 01:26:07 +00:00