Im Monatsraster wechselt ein gezogener Termin den Tag und behaelt seine
Uhrzeit; in Woche und Tag rastet er auf 15 Minuten ein. Der Greifpunkt
wandert mit, die Dauer bleibt erhalten, und eine gestrichelte Linie zeigt
die neue Startzeit vorab an.
Die Anzeige springt sofort ans Ziel (pendingMoves) und faellt zurueck,
wenn der Server den PATCH ablehnt. Ziehen darf nur, wer den Termin auch
aendern darf - das prueft der Server ohnehin erneut.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die bisherige Dokumentation beschrieb die Architektur, half aber niemandem, der
die Anwendung zum ersten Mal oeffnet. Dazu jetzt vier Kapitel:
- 07 Anleitung fuer Benutzer: was die Anwendung tut, jeder Bereich Schritt fuer
Schritt, warum der Signalton nur im Dashboard klingelt, was Loeschen eines
Suchagenten mitnimmt
- 08 Anleitung fuer Entwickler: einrichten, pruefen, Feld/Menuepunkt/Reiter/
Endpunkt hinzufuegen, dazu eine Tabelle der Fallen, die real Zeit gekostet
haben (Routen-Reihenfolge, FormData, Leerzeichen in Pfaden, Zeitstempel
koennen nur vorziehen, Kaskaden beim Loeschen)
- 09 Quellcode-Referenz: jede Datei mit ihren Exporten und den Zusagen, auf die
sich der Rest verlaesst
- 10 Glossar: Agent, Match, Lead, Opportunity und die Statuswerte der Datenbank
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Sperrfrist nach dem Start begann bei jedem Neustart von vorn. Zwei
Deployments im Abstand von zehn Minuten haben den faelligen Suchlauf damit
zweimal um eine halbe Stunde verschoben - er fand nie statt. Wer oefter als
alle SCANNER_SCHEDULER_OFFSET Minuten deployt, hat einen Scanner, der
automatisch nie sucht.
Der Zeitpunkt des letzten Laufs liegt jetzt in settings.last_scan_at, von der
Pipeline geschrieben (auch nach einem Abbruch, damit sich ein gescheiterter
Lauf nicht sofort wiederholt). Der Versatz greift nur noch, solange dort nichts
steht - also beim allerersten Start dieser Instanz, wo er gebraucht wird.
Der Scheduler liest den Wert zusaetzlich in jedem Tick: ein manueller Scan aus
der Oberflaeche schreibt ihn, weiss aber nichts von der Variablen im Scheduler.
Ohne den Abgleich konnte der Scheduler direkt hinter einem manuellen Lauf noch
einmal losziehen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der eigenstaendige Projekt Scanner zieht komplett ins CRM ein und laeuft
parallel zur bestehenden App weiter - jede geteilte Ressource ist verdoppelt
statt geteilt, damit die alte Installation unberuehrt bleibt:
- eigene Datenbank perinco_scanner, legt sich beim Start selbst an
- eigener SCANNER_ENCRYPTION_KEY, eigenes Upload-Verzeichnis
- eigener Scheduler mit Zeitversatz, damit nicht beide Instanzen gleichzeitig
mit denselben Portal-Cookies scrapen (Rate-Limits, CAPTCHA, doppelter RAM)
- Sperre gegen ueberlappende Laeufe: Scheduler und "Jetzt scannen" teilen sie,
ein zweiter Aufruf bekommt 409 statt doppelter OpenAI-Kosten
Backend unter /api/scanner hinter der CRM-Anmeldung; die HTTP-Basic-Auth des
Originals entfaellt. CV-PDFs kommen als Stream mit Token statt aus einem
statischen Verzeichnis. Bestandsdaten holt "npm run scanner:import" aus der
alten Datenbank, ohne sie zu veraendern.
Oberflaeche in Tailwind und CI-Farben neu gebaut: Menuepunkt Scanner mit
aufklappbaren Unterpunkten, Einstellungen als eigener Reiter.
Whisper hat keinen eigenen Menuepunkt mehr, sondern ist ein Reiter in den
Einstellungen. Damit diese Geraeteeinstellung jeder Rolle offensteht, sind die
Einstellungen jetzt fuer alle sichtbar - welche Reiter erscheinen, entscheidet
die Rolle.
Ausserdem: kein festes Admin-Passwort mehr im Quelltext, playwright exakt auf
1.60.0 gepinnt (nutzt den vorhandenen Chromium-Build des Servers), technische
Dokumentation mit Funktionszeichnungen unter docs/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
