Sascha WolfandClaude Opus 5
b8a78f609c
Neuer Menuepunkt ueber den Opportunities, mit dem Unterpunkt "Archiv". Die Liste traegt genau die Spalten, die beim Durchgehen zaehlen: Datum, Von, Anbieter, Kanal, Projekttitel, Berater, ein Knopf fuer die Uebernahme und die Symbole fuer Bearbeiten und Loeschen. Eingabe steht ueber der Liste und ist bewusst kein Dialog - Projekte kommen in Serie herein. Nach dem Eintragen bleiben Datum, Anbieter, Kanal und Berater stehen, damit drei Projekte aus einer Mail nicht dreimal dieselben Angaben kosten. Von, Anbieter und Berater schlagen frueher benutzte Werte vor. Was in der Liste keine Spalte hat, aber in der Opportunity vorkommt (Endkunde, Beschreibung, Tagessatz, Laufzeit, Projektpreis, Zeitraum, naechster Schritt, Notizen), klappt darunter auf. Eingang, Archiv und Loeschung ergeben sich aus dem Funddatum - 14 bzw. 90 Tage - und aus converted_at. Es gibt keine Zustandsspalte, die ein Job pflegen muesste und die von der Wirklichkeit abweichen kann. Der Loeschlauf raeumt beim Abruf der Liste, hoechstens einmal pro Stunde; die Abfragen filtern Faelliges ohnehin heraus. Die Uebernahme legt Opportunity und Merker in einer Transaktion an. Anbieter, Von, Kanal, Berater und Link haben in der Opportunity kein Feld und wandern als Herkunftsvermerk in die Notizen. Der Titel wird nur dann zum Link, wenn eine http(s)-Adresse hinterlegt ist: "hays.de/projekt/1" ergaenzt das Backend zu https://, und die Anzeige laesst nichts anderes durch als http und https. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dokumentation perinco CRM
Technische Dokumentation mit Funktionszeichnungen. Die Diagramme sind Mermaid und werden von Gitea direkt gerendert.
Neu hier? Wer die Anwendung benutzen will, fängt bei 07 Anleitung für Benutzer an. Wer daran entwickeln will, bei 08 Anleitung für Entwickler. Beide setzen keine Vorkenntnisse voraus.
| Kapitel | Inhalt |
|---|---|
| 01 Architektur | Topologie, Prozesse, Ports, Anfrageweg, Rollen |
| 02 Datenmodell | Tabellen beider Datenbanken als ER-Diagramme |
| 03 Projekt Scanner | Suchlauf von der Börse bis zum Treffer, Parallelbetrieb |
| 04 Diktat | Spracherkennung im Browser, Modell-Lebenszyklus |
| 05 Frontend | Ansichten, Menü, Komponentenkarte, Zustand |
| 06 Betrieb | Deployment, Umgebungsvariablen, Dienste, Störungssuche |
| 07 Anleitung für Benutzer | Bedienung aller Bereiche, Schritt für Schritt |
| 08 Anleitung für Entwickler | Einrichten, erweitern, bekannte Fallen |
| 09 Quellcode-Referenz | jede Datei, ihre Exporte und Zusagen |
| 10 Glossar | Agent, Match, Lead, Opportunity, Status- und Portalwerte |
| 11 Postfachanbindung | crm@perinco.de über Microsoft Graph, Kontakte aus Mails |
Die Designentscheidungen und die Messwerte zur Spracherkennung stehen im README des Projekts.
Das Ganze in einem Bild
flowchart TB
subgraph Browser
SPA["React-SPA<br/>Vite-Build"]
WSP["Whisper im Web Worker<br/>WebGPU / WASM"]
end
subgraph Server["Server 212.227.135.41"]
AP["Apache<br/>:443"]
API["Express-Backend<br/>127.0.0.1:5006"]
SCH["Scanner-Scheduler<br/>node-cron"]
MSCH["Mail-Scheduler<br/>node-cron"]
PW["Playwright<br/>Chromium"]
DB1[("MariaDB<br/>perinco_CRM")]
DB2[("MariaDB<br/>perinco_scanner")]
ALT["alte Scanner-App<br/>:5005"]
DB3[("MariaDB<br/>project_scanner")]
end
OAI["OpenAI<br/>gpt-4o-mini"]
BOERSE["Projektbörsen<br/>freelancermap, hays, ..."]
GRAPH["Microsoft Graph<br/>crm@perinco.de"]
SPA -->|"HTTPS /api"| AP
AP --> API
API --> DB1
API --> DB2
SCH --> PW
PW --> BOERSE
SCH --> OAI
SCH --> DB2
API -.-> SCH
API -.-> MSCH
MSCH -->|"Delta Query, nur lesend"| GRAPH
MSCH --> DB1
ALT --> DB3
ALT --> BOERSE
SPA -.->|"Audio bleibt im Browser"| WSP
classDef alt fill:#f7f7f7,stroke:#9a9a9a,stroke-dasharray: 4 3
class ALT,DB3 alt
Gestrichelt: die ursprüngliche Scanner-App, die bis zur Ablosung parallel weiterläuft. Sie hat ihre eigene Datenbank und wird vom CRM nicht angefasst.