RUDI RegioFrucht Unternehmens Daten Intelligenz

RUDI ist die KI-gestuetzte Unternehmens-Intelligenz der Regio Frucht GmbH (kuechenfertige Verarbeitung von Obst, Gemuese und Salaten). RUDI kombiniert einen Claude-basierten KI-Chat mit einem vollstaendigen QMS-System nach IFS Food 8.

Modul-Uebersicht

Alle RUDI-Module auf einen Blick. Fuer die interaktive Version: System-Karte

Architektur

Internet
  |
  HTTPS (Let's Encrypt)
  |
Nginx Reverse Proxy (:443)
  |-- Basic Auth (global)
  |-- Security Headers (HSTS, CSP, XSS)
  |-- Rate Limiting (10 req/min Chat)
  |
  |-- /              --> /var/www/html/         (Zentrale)
  |-- /qms/          --> /var/www/qms/          (QMS Dashboard)
  |-- /system/       --> /var/www/html/system/  (System Dashboard)
  |-- /dateien/      --> /var/www/dateien/       (Dateibrowser)
  |-- /chat/         --> proxy 127.0.0.1:3456   (Node.js App)
  |-- /chat/api/*    --> proxy 127.0.0.1:3456   (REST API)

Node.js/Express (:3456, nur localhost)
  |-- Claude API (claude-opus-4-6)
  |-- Agentic Tool Loop (max 10 Iterationen)
  |-- 14 Tools
  |-- SSE Streaming

Projektstruktur

Schnellstart

Was kann ich RUDI fragen?

• QMS: "Zeige die Gap-Analyse fuer Kapitel 4" / "Erstelle ein Dokument fuer 4.10.1" / "Batch-Plan fuer alle gruenen Anforderungen"
• Dateien: "Lies die Datei qms/QMS/unsortiert/..." / "Was steht in der Excel?"
• System: "Wie ist der Speicherstand?" / "Welche Dienste laufen?"
• Aufgaben: "Erstelle eine monatliche Pruefung fuer Temperaturkontrolle"

Zentrale

Die Startseite unter / zeigt 4 Kacheln im Apple-Glasmorphism-Design:

• Chat – KI-Chat mit vollem Tool-Zugriff
• System & Dateien – Server-Status (Live-Badge) + Dateibrowser-Zugang
• QMS – IFS Gap-Analyse Dashboard (mit integriertem Aufgaben-Tab, Live-Badge)
• Dokumentation – Diese Seite

Das System-Badge laedt dynamisch den Server-Status und zeigt "Alles OK" oder Warnungen an.

Chat

Der Chat unter /chat/ ist das Herztueck von RUDI. Features:

• Echtes Streaming: Text erscheint Zeichen fuer Zeichen (via client.messages.stream())
• Live Tool-Status: Zeigt in Echtzeit welche Tools RUDI gerade nutzt (Dateien lesen, Dokumente erstellen etc.)
• Sidebar: Chat-Liste mit Suche, Gruppierung (Chats/QMS/Recurring/Admin), Filter-Pills (Alle/Chats/QMS/Aufgaben), Erstellen/Umbenennen/Loeschen
• Papierkorb: Geloeschte Chats werden in Papierkorb verschoben mit Wiederherstellen-Option
• Markdown-Rendering: Tabellen, Code-Bloecke mit Syntax-Highlighting und Kopier-Button
• Datei-Upload: Drag & Drop oder Dateiauswahl, Dateien werden im Chat referenziert
• Spracheingabe: Web Speech API (live) oder Whisper-Transkription (Audio-Aufnahme)
• Dark/Light Mode: System-Praeferenz + manueller Toggle
• Auto-Titel: Chats werden nach der ersten Antwort automatisch benannt

Kontext-Links

Der Chat kann mit Kontext gestartet werden:

Dokumenten-Pipeline

Die Dokumenten-Pipeline unter /pipeline/ verarbeitet eingehende Papierdokumente automatisch. Dokumente werden per Scanner (FTP/FTPS) oder manuellen Upload eingespeist.

Pipeline-Ablauf (Phase 5: Dual-Processing + Vorgang-Verlinkung)

1. Eingang: Scanner sendet PDF per FTPS an eingang/ oder eingang_personal/
2. OCR (Dual-Processing): pdfplumber/Tesseract PLUS Claude Vision Cross-Check (Flag pipeline_vision_cross ON)
   • Similarity-Ratio > 0.80: Vision-Text bevorzugt (besser bei Tabellen/Layout), conf=0.95
   • Similarity-Ratio ≤ 0.80: Beide Texte kombiniert, conf=0.70
   • Vision fehlgeschlagen: Tesseract-Fallback automatisch
   • Tagesbudget: max 50 Vision-Calls/Tag (PIPELINE_VISION_MAX). Audit-Log: modul=pipeline-vision
3. Lieferanten-Normalisierung: Alias-Resolver gegen lieferant_aliase-Tabelle
4. Dedup-Check: SHA-1-Hash ueber Lieferant+Belegnummer+Betrag+Datum; Duplikate nach ~/pipeline/duplikate/
5. Klassifikation: Claude API (Sonnet) extrahiert Metadaten als JSON
6. Ablage: Datei umbenannt + verschoben
7. DB-Eintrag: pipeline.db mit allen Daten inkl. dedup_hash
8. Vorgang-Verlinkung (NEU): Pipeline-Dokument wird mit Vorgang in einkauf.db verlinkt (vorgang_referenz.beleg_db='pipeline'). Fuzzy-Lieferant-Match, offener Vorgang ±30 Tage. Kein Vorgang: auto-angelegt.
9. Abgleich: Automatischer Abgleich Lieferschein/Rechnung

Lieferanten-Aliase

Tabelle lieferant_aliase in pipeline.db normalisiert Schreibvarianten auf kanonische Namen. Migrations-Skript: ~/pipeline/migrations/001_lieferant_aliase.py (idempotent). Aktuell 10 Aliase konfiguriert (Stand 2026-04-27).

Dedup-Hash & Duplikatserkennung

Spalte dedup_hash (SHA-1 ueber Lieferant|Belegnummer|Betrag|Datum) verhindert Doppeleintraege bei Re-Upload. Bestehende Duplikate werden in ~/pipeline/duplikate_vorschlag.json dokumentiert (kein automatisches Loeschen). Migrations-Skript: ~/pipeline/migrations/002_dedup_hash.py (idempotent, Backfill aller vorhandenen Dokumente).

Dashboard-Funktionen

• Statistik-Karten: Heute verarbeitet, Gesamt, Fehler, Offene Abgleiche
• Dokumente-Tab: Dokumentenliste mit Filtern (Kategorie, Status, Suchfeld), klickbare Detail-Ansicht
• LS/RE-Abgleich-Tab: Uebersicht der automatischen Lieferschein/Rechnungs-Zuordnungen
• Alerts-Tab: Fehler-Meldungen und offene Rechnungen ohne Abgleich
• Upload: Zwei Upload-Buttons – allgemein (nach eingang/) und Personal (nach eingang_personal/, vertraulich)
• Status-Aenderung: Im Detail-Modal kann der Status manuell geaendert werden

Dokument-Kategorien

Scanner-Anbindung (FTPS)

• Scanner: Sharp BP-56C26 per FTP/FTPS (vsftpd)
• Profil "RUDI - Allgemein": User scanner → eingang/
• Profil "RUDI - Personal": User scanner-personal → eingang_personal/ (sofort vertraulich)
• SSL: Let's Encrypt Zertifikat, Passive Mode Ports 40000-40100

Hintergrundprozess

• Service: Kein eigenstaendiger systemd-Service. Start manuell: cd ~/pipeline && source venv/bin/activate && python pipeline.py
• Logs: sudo journalctl -u regio-pipeline -f
• Pfad: ~/pipeline/ (pipeline.py, classifier.py, ocr.py, db.py, config.py, vorgang_link.py [NEU Phase 5])
• Migrations: ~/pipeline/migrations/ (001_lieferant_aliase.py, 002_dedup_hash.py)
• DB: ~/pipeline/pipeline.db (SQLite, WAL-Modus, Tabellen: dokumente, abgleich_log, pipeline_log, mitarbeiter, artikel_positionen, lieferant_aliase)
• Duplikat-Report: ~/pipeline/duplikate_vorschlag.json
• Duplikate-Ablage: ~/pipeline/duplikate/ (Re-Uploads mit gleichem Hash)
• DSGVO: Personaldokumente werden als vertraulich markiert, OCR-Text wird nicht gespeichert

QMS Dashboard

Das QMS Dashboard unter /qms/ ist als Tab-System aufgebaut mit zwei Tabs:

Tab: Dashboard (Gap-Analyse)

• Gesamt-Header: Stats-Karten (Total/Abgedeckt/Teilweise/Fehlend/Offene Aufgaben), Fortschrittsbalken mit 3 Farbsegmenten
• 5 Kapitel-Karten: Aufklappbar mit Ampel-Badges (Gruen/Gelb/Rot), Abdeckungsprozent, Mini-Fortschrittsbalken
• Anforderungsliste: Sortiert (Rot zuerst), mit Status-Icon, IFS-Ref, Task-Badge, Dokumentenanzahl
• Detail-Panel: Tasks (Checkbox + Doppelklick-Edit + Loeschen), Notizen (Auto-Save), Dokumente
• Quick-Chat: Slide-in-Panel mit IFS-Kontext, Quick-Action-Chips, SSE-Streaming
• Upload: Ordner-Upload (webkitdirectory), Drag & Drop, Zielordner-Auswahl, Fortschrittsbalken
• Eigene Punkte: Custom-Tasks mit Label und Checkbox

Tab: Aufgaben

Integrierter Aufgaben-Tab (erreichbar ueber /qms/#aufgaben) mit:

• IFS-Aufgaben: Pro-Anforderung Tasks mit Checkbox, Bearbeiten, Loeschen
• Wiederkehrende Aufgaben: Recurring Tasks mit Ampelstatus, Erledigen-Button, Historie
• Stats-Leiste: Gesamt/Offen/Erledigt/Ueberfaellig Zaehler
• Filter: Alle/Offen/Erledigt/Ueberfaellig mit Such-Funktion
• Lazy Loading: Daten werden erst beim ersten Tab-Wechsel geladen
• Tab-Badge: Zeigt Anzahl offener Aufgaben im Tab-Button

Ampelsystem

Dateibrowser

Der Dateibrowser unter /dateien/ zeigt die gesamte RUDI-Verzeichnisstruktur:

• Baumansicht: Laedt tree.json (generiert von generate-tree.sh)
• Echtzeitsuche: Filter ueber Dateinamen
• Dateivorschau: PDF (iframe), Bilder, Excel (Handsontable), Word (mammoth.js), Markdown, Code (Syntax-Highlighting)
• Download-Button fuer jede Datei
• Upload: Gleiche Upload-Funktion wie QMS Dashboard

System Dashboard

Das System Dashboard unter /system/ zeigt Server-Informationen in Echtzeit:

• Status-Karten: Uptime, CPU Load, RAM-Nutzung, Disk-Nutzung, Dienste-Status
• Dienste-Uebersicht: rudi-chat, nginx, fail2ban, ufw mit Live-Status (aktiv/inaktiv)
• Detailsektionen: CPU-Modell, RAM-Details, Disk-Details, System-Info (aufklappbar)
• Fortschrittsbalken: Farbcodiert (gruen/gelb/rot) je nach Auslastung
• Auto-Refresh: Daten werden alle 60 Sekunden automatisch aktualisiert
• Integrierter Chat: RUDI fragen-Button oeffnet System-Chat mit Kontext-Chips

Die Daten kommen von der API-Route /chat/api/system/status, die CPU, RAM, Disk und Services ueber das os-Modul und systemctl abruft.

System-Karte (/system/map.html)

Die System-Karte bietet eine interaktive, statische Uebersicht aller RUDI-Komponenten als aufklappbarer Baum:

• Interaktiver Baum: 108 Komponenten in 7 Hauptkategorien (Backend, Frontend, KI & Wissen, Claude Code, Infrastruktur, Externe Dienste)
• Echtzeit-Suche: Filterung des Baums nach Name oder Beschreibung
• Detail-Panel: Klick auf einen Knoten zeigt Beschreibung, Dateipfad, Badge und Unterkomponenten
• Status-Dots: Farbkodierung gruen=aktiv, orange=in_arbeit, grau=pausiert, rot=problem
• Kein API-Aufruf: Vollstaendig statisch — keine Backend-Abhaengigkeit
• Responsive: Mobile zeigt Baum oben, Detail-Panel darunter

Änderungsvorschläge

Die Seite /vorschlaege/ sammelt Ideen, Verbesserungen und Bugfixes für RUDI. Vorschläge können manuell per Formular oder im Gespräch mit RUDI erstellt werden.

Funktionen

• Manuell erstellen: Button "Neuer Vorschlag" leitet zu /vorschlaege/detail.html (eigenständige Seite, kein Modal)
• Detailseite (/vorschlaege/detail.html): Vollständiges Formular mit Titel, Beschreibung, Kategorie, Priorität, Status (nur Edit), Drag&Drop-Datei-Upload, Bild-Galerie mit Lightbox, Datei-Löschen
• Per RUDI-Chat: "RUDI fragen"-Button öffnet das Chat-Panel – RUDI legt Vorschläge automatisch über Tools an (vorschlag_erstellen, vorschlaege_lesen, vorschlag_aktualisieren)
• Lightbox: Bild-Vollansicht mit Vor/Zurück-Navigation, Tastatur-Steuerung (ESC, Pfeiltasten), Download-Link
• Medien-Upload im Chat: Dateien können auch direkt im RUDI-Chat angehängt werden (Büroklammer-Button oder Drag & Drop)
• Bearbeiten: Vorschläge aktualisieren, Status ändern (Offen, In Arbeit, Erledigt, Abgelehnt)
• Löschen: Vorschläge mit Bestätigungsdialog entfernen (inkl. aller hochgeladenen Dateien)
• Filter: Nach Status, Kategorie und Priorität filtern
• Datei-Vorschau: Bild-Galerie in der Detailseite, Thumbnails in den Listenkarten

RUDI-Tools (Vorschläge-Kontext)

Wenn das Chat-Panel auf der Vorschläge-Seite geöffnet wird, erhält RUDI drei zusätzliche Tools:

API-Endpunkte

Speicherung

• Daten: ~/rudi-chat/vorschlaege.json (JSON-Array, atomic writes)
• Dateien: ~/uploads/vorschlaege/{id}/ (pro Vorschlag ein Ordner)
• Claude Code: Liest vorschlaege.json direkt vom Dateisystem, um Vorschläge zu besprechen und umzusetzen

Agentic Loop

RUDI nutzt einen agentic Tool-Loop mit Claude. Das bedeutet: Claude kann eigenstaendig Tools aufrufen, die Ergebnisse lesen, und weitere Tools aufrufen – bis zu 10 Iterationen pro Nachricht.

Modell: claude-opus-4-6 | Max Tokens: 4096 | Streaming: Echtes SSE-Streaming (Zeichen fuer Zeichen)

Live Tool-Status

Waehrend RUDI im Hintergrund arbeitet (Dateien liest, Dokumente erstellt), zeigt das Chat-Frontend live an, welches Tool gerade laeuft:

• Blau pulsierend = Tool arbeitet (z.B. "Datei lesen – VA01_Hygienisch_Arbeiten.docx")
• Gruener Haken = Tool abgeschlossen
• Die Anzeige blendet sich nach Abschluss automatisch aus

Papierkorb

Geloeschte Chats werden nicht sofort entfernt, sondern in einen Papierkorb verschoben (soft delete):

• Papierkorb-Bereich unten in der Chat-Sidebar mit Zaehler
• Wiederherstellen oder endgueltig Loeschen pro Chat
• "Alle endgueltig loeschen" leert den gesamten Papierkorb
• Beim Loeschen werden automatisch alle IFS-Verknuepfungen (linkedChats in Annotations) bereinigt

RUDI Tools

RUDI hat 17 Tools zur Verfuegung. Jedes Tool wird von Claude eigenstaendig aufgerufen.

Datei & System

QMS Analyse

QMS Aktionen

Wiederkehrende Aufgaben

Pipeline

Gap-Analyse

Die Gap-Analyse vergleicht 127 IFS Food 8 Grundstufe-Anforderungen (davon 11 KO-Anforderungen) mit den vorhandenen Dokumenten.

Datenquellen

Berechnung

Fuer jede Grundstufe-Anforderung wird gezaehlt, wie viele Dokumente aus dem Mapping zugeordnet sind. >=2 = Gruen, 1 = Gelb, 0 = Rot.

Dokumente erstellen

RUDI erstellt QMS-Dokumente in einem mehrstufigen Dialog:

1. Vorhandene pruefen: Schon Dokumente fuer diese Anforderung vorhanden?
2. Infos klaeren: Fehlende Informationen beim Benutzer abfragen (keine Platzhalter!)
3. Entwurf zeigen: Vollstaendiger Entwurf im Chat
4. Bestaetigung abwarten: Benutzer gibt OK
5. Dokument erstellen: DOCX aus Vorlage generieren

Dokumenten-Kodierung

[Typ]-[Kapitel].[Nummer]_[Titel]_v[Version].docx

Beispiel: VA-4.10.001_Reinigungsplan_v1.0.docx

Vorlage

Alle Dokumente basieren auf QMS-Vorlage-Regio-Frucht.docx:

• Header: Firmenlogo, Adresse, Handelsregister + Leiste mit Dok-ID, Version, Dokumentenname
• Footer: Erstellt von / Geprueft von / Freigabe von (mit Unterschriften-Bildern), Datumsfelder, Referenzzeile
• Body: Wird mit Markdown-Inhalt befuellt (Ueberschriften, Text, Listen, Tabellen)

Word-Tabellen

Markdown-Tabellen im Inhalt werden als formatierte Word-Tabellen gerendert:

• Header-Zeile: Akzentfarbe (#04B3D6) mit weisser Schrift
• Datenzeilen: Zebra-Streifen (#F0F8FF)
• Mehrzeilige Zellen: \n fuer Zeilenumbruch

Batch-Erstellung

RUDI kann fuer alle gruenen/gelben Anforderungen automatisch Dokumente erstellen:

Wichtig: RUDI verwendet nur echte Daten aus den Quelldokumenten – keine erfundenen Inhalte.

Wiederkehrende Aufgaben

Pruefungen, Checklisten und Formular-Durchgaenge koennen als wiederkehrende Aufgaben angelegt werden:

• Duplikat-Erkennung: Vor der Erstellung prueft RUDI automatisch ob eine aehnliche Aufgabe existiert (gleiche IFS-Ref oder aehnlicher Titel). Bei Treffer wird eine Warnung angezeigt – mit force=true kann trotzdem erstellt werden.
• Formblatt-Pruefung: Bei der Erstellung von Formblaettern prueft RUDI ob bereits eine passende wiederkehrende Aufgabe existiert und weist darauf hin.
• Intervalle: Taeglich, Woechentlich, Monatlich, Vierteljaehrlich, Halbjaehrlich, Jaehrlich
• Ampelstatus: Ueberfaellig (Rot), Bald faellig (<14 Tage, Gelb), OK (Gruen)
• Erledigung: Ueber Chat, QMS-Dashboard oder API
• Historie: Jede Erledigung wird mit Datum, Person und Notizen protokolliert

Kundenreklamationen

Das Reklamationsmodul ermoeglicht die strukturierte Erfassung, Bearbeitung und Dokumentation von Kundenreklamationen gemaess IFS 5.7.2–5.7.4.

Reklamation anlegen

Erreichbar ueber QMS Dashboard → Reklamationen → Neue Reklamation oder direkt unter /qms/reklamation.html.

• E-Mail-Import: .eml und .msg-Dateien (Outlook) per Drag & Drop oder Klick hochladen. RUDI analysiert automatisch Absender, Betreff und Inhalt und fuellt die Formularfelder vor.
• E-Mail-Text: Alternativ kann der E-Mail-Text direkt eingefuegt werden.
• Bild-Upload: .jpg, .png, .webp Bilder werden per Claude Vision analysiert (z.B. Fotos von beschaedigter Ware). Max. 15 MB pro Bild.
• PDF/Text-Upload: .pdf und .txt Dateien werden als Text extrahiert und mitanalysiert.
• Dateigroesse: Max. 50 MB pro E-Mail-Datei. Bei groesseren E-Mails mit Bildern kann die Analyse 1–2 Minuten dauern.

Formularfelder

Entwurf & Speicherung

• Auto-Entwurf: Bei neuen Reklamationen werden Formulardaten automatisch im Browser (localStorage) gespeichert. Beim erneuten Oeffnen wird angeboten, den Entwurf wiederherzustellen.
• Status-Anzeige: Rechts oben zeigt ein Indikator den aktuellen Speicher-Status (Entwurf / Gespeichert / Ungespeicherte Aenderungen).
• Bestehende Reklamationen: Werden ueber die ID in der URL geladen (/qms/reklamation.html?id=rek_xxx).

RUDI Chat-Integration

Ueber den Button “Mit RUDI bearbeiten” (unten rechts) oeffnet sich das Chat-Panel mit vollem Reklamationskontext. Quick-Actions:

• Reklamationsformular erstellen – Formblatt (FB) als DOCX mit QMS-Vorlage
• Stellungnahme verfassen – Verfahrensanweisung (VA) als DOCX an den Kunden
• Korrekturmassnahmen – Arbeitsanweisung (AA) mit Ursache, Massnahme, Verantwortlichem, Frist (IFS 5.7.3)
• 8D-Report – Formblatt als DOCX
• Was tun? – Uebersicht der erforderlichen QMS-Dokumente

RUDI nutzt die vorhandenen Reklamationsdaten automatisch und erstellt Dokumente mit der Regio Frucht QMS-Vorlage (Kopf-/Fusszeile, Dok-ID, Version).

Bilder-Vorschau

Hochgeladene Bilder (JPG, PNG, WebP) werden als Thumbnail-Galerie angezeigt. Ein Klick oeffnet die Lightbox mit Vollbild-Ansicht, Pfeil-Navigation (auch per Tastatur), und optionalem Download-Button.

Dateispeicherung

Dateien aus E-Mail-Analysen werden zunaechst in einem Staging-Bereich zwischengespeichert. Beim Speichern der Reklamation werden sie automatisch in den permanenten Ordner (~/uploads/reklamationen/{rek_id}/) verschoben und mit der Reklamation verknuepft.

Bildanalyse (Claude Vision)

RUDI kann Bilder aus Reklamationen visuell analysieren (Tool: reklamation_bild_analysieren). Dabei werden Qualitaetsmaengel wie Druckstellen, Schimmel, Verfaerbungen, Fremdkoerper oder Verpackungsschaeden erkannt.

• Bilder > 4 MB werden automatisch verkleinert (max. 2000×2000px, JPEG 80%)
• Max. 4 Bilder pro Analyse, Bilder < 1 KB werden uebersprungen (Logos/Icons)
• Bildverkleinerung via sharp (serverseitig)
• Aufruf ueber Chat-Panel: “Was ist auf den Bildern zu sehen?” oder Quick-Action Chips

Reklamationssuche (ChromaDB)

Historische Reklamationen werden in der Vektordatenbank indexiert. Das Tool reklamationen_suche findet aehnliche Faelle, z.B. “Druckstellen bei Erdbeeren” oder “Temperaturproblem Lieferung”. Hilfreich um Muster zu erkennen.

IFS-Referenz

Vektordatenbank & Semantische Suche

RUDI nutzt eine Vektordatenbank (ChromaDB) kombiniert mit Google Gemini Embedding 2, um Dokumente, Bilder und Reklamationen inhaltlich durchsuchbar zu machen – nicht nur nach Stichworten, sondern nach Bedeutung.

Wie funktioniert das?

Suchprozess am Beispiel

Szenario: Du suchst Bilder von einem kaputten Riemen an der GS 10.

Du: "Zeig mir Bilder von kaputten Riemen"

"kaputter Riemen" → [0.21, -0.39, 0.11, 0.85, ...]

RUDI: "Ich habe 2 passende Medien gefunden:
  - Bild: gerissener_riemen.jpg (GS 10, Kategorie: Fehler)
  - Video: riemenwechsel.mp4 (GS 10, Kategorie: Wartung)"

Warum findet die Suche auch Bilder OHNE Beschreibung?

Gemini Embedding 2 ist multimodal – es versteht Text UND Bilder gleichzeitig. Wenn du ein Foto hochlaedst, erzeugt Gemini einen Vektor der den visuellen Inhalt repraesentiert. Dieser Vektor liegt im selben Raum wie Text-Vektoren:

Bild hochladen                    Text-Suche
     |                                |
     v                                v
Gemini "sieht" das Bild       Gemini "versteht" den Text
     |                                |
     v                                v
Vektor: [0.22, -0.40, ...]    Vektor: [0.21, -0.39, ...]
     |                                |
     +----------- aehnlich! ----------+
                    |
                    v
              TREFFER!

Was passiert beim Bild-Upload?

1. Bild wird hochgeladen
      |
      v
2. Datei gespeichert in ~/maschinen/medien/{id}/{YYYY-MM}/
      |
      v
3. Gemini Vision analysiert das Bild automatisch
   → "Foto zeigt ausgefransten Antriebsriemen mit Verschleissspuren"
      |
      v
4. Beschreibung wird in Datenbank gespeichert
      |
      v
5. Zwei Embeddings werden erzeugt:
   a) Bild-Vektor (multimodal, vom Foto selbst)
   b) Text-Vektor (von der Auto-Beschreibung)
      |
      v
6. RUDI weiss jetzt was auf dem Bild ist
   und kann es per Textsuche finden

OCR-Fallback (seit 27.03.2026)

Gescannte PDFs (Bilder statt Text) werden automatisch per Tesseract OCR gelesen. Der Fallback greift systemweit — egal in welchem Modul oder Chat ein PDF hochgeladen wird.

Ablauf: pdfplumber versucht Text zu extrahieren (schnell). Nur wenn kein/wenig Text gefunden wird (<50 Zeichen/Seite), startet Tesseract OCR als Fallback (2-5 Sek/Seite, max 20 Seiten).

Force-Reprocessing: Bereits verarbeitete Anleitungen koennen mit force=true erneut verarbeitet werden (z.B. nach OCR-Update oder wenn ein Scan beim ersten Mal nicht erkannt wurde).

ChromaDB Collections

Kosten

Gesamt bei intensiver Nutzung: unter $1/Monat.

Maschinenmanagement

Das Maschinenmodul verwaltet Produktionsmaschinen (Schneiden, Waschen, Verpacken, Kuehlung) mit Stammdaten, Bedienungsanleitungen, Wartungsplaenen und Medien. Erreichbar unter /maschinen/.

Funktionen

• Maschinenakte – Stammdaten, Hersteller, Standort, Kategorie, Inbetriebnahme
• Bedienungsanleitungen – PDF hochladen, seitenweise in ChromaDB indexiert, per RUDI durchsuchbar
• Wartungsplaene – automatisch aus Anleitung extrahiert (Claude) oder manuell erstellt
• Wartungsprotokolle – Dokumentation durchgefuehrter Wartungen
• Taegliche Wartungsueberwachung – systemd Timer prueft faellige Wartungen

Maschinen-Wissen

RUDI speichert maschinenspezifisches Wissen dauerhaft – Tipps, Warnungen und Erfahrungswerte die nicht in der Bedienungsanleitung stehen.

Du im Chat: "Merk dir: Beim Riemenwechsel an der GS 10
             muss die Spannung auf 3,5 Nm gestellt werden"
     |
     v
RUDI speichert als Hinweis:
  Typ:    Tipp
  Inhalt: "Beim Riemenwechsel Spannung auf 3,5 Nm einstellen"
     |
     v
Bei jeder zukuenftigen Frage zur GS 10:
  RUDI laedt automatisch alle aktiven Hinweise
  und beruecksichtigt sie in der Antwort.

Hinweise-Typen: Tipp (Praxistipp), Warnung (Sicherheit), Fehler (bekannte Probleme), Prozess (Arbeitsablaeufe). Max. 20 aktive Hinweise pro Maschine werden in den Chat-Kontext geladen.

Medien & Dokumentation

Jede Maschine kann mit Bildern, Videos und Dokumenten angereichert werden:

• Bilder (JPG, PNG, WEBP) – automatische Beschreibung via Gemini Vision, multimodal embedded in ChromaDB
• Videos (MP4, MOV, WebM) – Beschreibung wird als Text embedded, max. 100 MB
• Upload ueber Detailseite oder Chat
• Kategorien: Fehler, Wartung, Zustand, Sonstiges

Medien sind ueber die semantische Suche auffindbar: "Zeig mir Bilder von kaputten Riemen" → RUDI durchsucht ChromaDB und findet passende Fotos (siehe Semantische Suche).

Fuhrparkmodul

Das Fuhrparkmodul verwaltet alle 11 Firmenfahrzeuge mit Stammdaten, TUeV-Terminen, Wartungsplaenen, KM-Eintraegen, Dokumenten und Fahrerkarten. Datenbasis: SQLite unter ~/fuhrpark/fuhrpark.db.

Fahrzeugtypen

• kuehl_lkw – Kuehl-LKW (Fiat Ducato 3,5t, MFTBC 7,5t, MAN TGL 12t)
• lkw – LKW ohne Kuehlung (Mercedes 308 D)
• e_auto – Elektrofahrzeuge (Tesla Model Y, Mercedes EQE 500) – keine AU noetig
• pkw – PKW (Mercedes AMG C 63 S, Audi Q7, Audi S3)

TUeV-Verwaltung

TUeV-Faelligkeiten werden im Format MM/YYYY gespeichert. Die API liefert Fahrzeuge nach TUeV-Dringlichkeit sortiert. Bremswerte aus der HU werden als JSON in der TUeV-Historie gespeichert.

Wartungsplanung

Wartungsplaene haben zeit- und/oder KM-basierte Intervalle. Bei Protokolleintrag wird naechste_faellig automatisch berechnet und km_stand im Fahrzeug aktualisiert.

Dateipfade

• Datenbank: ~/fuhrpark/fuhrpark.db
• Schema: ~/fuhrpark/schema.sql
• Seed-Script: ~/fuhrpark/seed.js (einmalig, 11 Fahrzeuge)
• Dokumente: ~/fuhrpark/dokumente/{fahrzeug_id}/
• Fahrerkarten: ~/fuhrpark/dokumente/{fahrzeug_id}/fahrerkarten/
• Tacho-Uploads: ~/fuhrpark/dokumente/tacho/
• Tacho-Parser-Binary: ~/fuhrpark/bin/dddparser
• Lib: ~/rudi-chat/lib/fuhrpark-db.js, ~/rudi-chat/lib/tacho-parser.js, ~/rudi-chat/lib/tacho-violations.js
• Route: ~/rudi-chat/routes/fuhrpark.js

API-Endpunkte

Alle Endpunkte sind unter /chat/api/ erreichbar (via Nginx Proxy). Basis: https://rudi-regiofrucht.de

Chat

Dateien

QMS

Reklamationen

Pipeline

Personal-Routen (nur Admin)

Fuhrpark

Tacho-Auswertung

Digitale Tachograph-Auswertung (.ddd-Dateien). Frontend: /fuhrpark/tacho.html. Parser-Binary: ~/fuhrpark/bin/dddparser. Gespeichert unter ~/fuhrpark/dokumente/tacho/. Verstoesspruefung nach EU VO 561/2006.

Team-Chat

Interner Messenger unter /team/ — Direktnachrichten + Gruppen, Medienversand, Sprachnachrichten, automatische Uebersetzung (DE/RO) und WebSocket-Echtzeit.

Seiten

Features

• Medien: Bilder (Canvas-Resize auf max. 1920px), Dateien, Sprachnachrichten (MediaRecorder, iOS mp4/webm Fallback)
• Uebersetzung: content_translated-Feld: Haupttext in Nutzersprache, Original klappbar
• Antworten: reply_to-Vorschau in Bubble + Compose-Bar
• Bearbeiten/Loeschen: per Long-Press-Kontextmenu (eigene Nachrichten, Bearbeiten max. 15 Min)
• WebSocket: Reconnect mit exp. Backoff (1s/2s/.../30s), Ping alle 25s
• Online-Status: gruener Punkt am Avatar, Header-Status in DM
• Bottom-Nav: Home / Chat / Ideen / Mehr — einheitlich auf allen 3 Seiten

API-Basis

/chat/api/team-chat/ (Nginx Proxy → :3456/)

Kommunikation (E-Mail & Kalender)

Das Kommunikationsmodul unter /kommunikation/ integriert E-Mail und Kalender ueber die Microsoft Graph API mit zwei Shared Mailboxen.

Mailboxen

Authentifizierung

Azure App Registration mit Client Credentials Flow (app-only, kein User-Login). Berechtigungen: Mail.Read, Mail.ReadWrite, Mail.Send, Calendars.Read, Calendars.ReadWrite, User.Read.All. Die Berechtigungen gelten tenant-weit fuer beide Mailboxen. Credentials in /etc/environment: AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, RUDI_MAILBOX, QMS_MAILBOX.

E-Mail-Tab (rudi@)

Layout: Outlook-Style 3-Spalten (Ordner-Sidebar | E-Mail-Liste | Lesebereich). Ordner: Posteingang, Gesendet, Entwuerfe, Papierkorb, Junk, Archiv. Features: Datum-Gruppierung (Heute/Gestern/Woche/Aelter), CID-Inline-Bilder, Signatur (global + individuell), Antworten/Weiterleiten, Sync-Button, Ungelesen-Filter.

Signatur: Gespeichert in auth.db (Tabelle email_signatures). Global (Admin) + individuell (pro User). Wird serverseitig an ausgehende E-Mails angehaengt. API: GET/PUT /chat/api/email/signatur, GET/PUT /chat/api/email/signatur/global.

E-Mail-Sync: Polling alle 5 Minuten via Graph API Delta Query. Neue/geaenderte E-Mails werden in die lokale SQLite-DB gespeichert (AES-256-GCM verschluesselt). Geloeschte oder verschobene E-Mails werden ueber @removed-Marker aus der Delta-Response erkannt und automatisch aus dem lokalen Cache entfernt. Bei verwaisten Eintraegen (z.B. vor dem Fix geloescht) werden beim manuellen Sync (POST /chat/api/email/sync) alle DB-Eintraege gegen den Live-Inbox abgeglichen und nicht mehr vorhandene Mails bereinigt.

Kalender-Tab

Wochenansicht mit Zeitraster (6:00–21:00 Uhr, 48px/Stunde). Mitarbeiter-Kalender: Checkbox-Liste in der Sidebar, farbcodiert (blau/gruen/orange/lila/rot). Mehrere Kalender gleichzeitig als Overlay. Termine: Erstellen per Klick auf Zeitslot oder Button, Bearbeiten/Loeschen per Klick auf Event. Zeitzonen: Europe/Berlin.

QMS-E-Mail (qms@)

Sicherheitskonzept: RUDI darf ueber qms@ KEINE E-Mails direkt senden. Sende-Blockierung auf Graph-API-Ebene (assertSendAllowed). Nur Entwuerfe (Drafts) koennen erstellt werden. User sendet in Outlook.

Dashboard-Integration: Im QMS-Dashboard (/qms/) zeigt eine kompakte Sektion die letzten QMS-E-Mails + Ungelesen-Badge + Links zu Outlook Inbox und Entwuerfe.

API-Endpoints (unter /chat/api/qms/email/, geschuetzt mit requireModule('qms')):

RUDI-Chat-Tools

Technische Details

• Backend: lib/microsoft-graph.js (Multi-Mailbox: MAILBOXES-Registry, resolveMailbox(), Draft-Funktionen, Sende-Blockierung)
• Datenbank: ~/email/email.db (SQLite, WAL-Modus, Spalte mailbox fuer Trennung, QMS-IDs mit Prefix qms:)
• Polling: Alle 5 Min per Delta-Query. RUDI bei t=0, QMS versetzt bei t+2.5min. QMS: nur Metadaten (kein Body).
• Nginx: Dedizierte Location-Bloecke: /chat/api/email/, /chat/api/kalender/. QMS-E-Mail laeuft ueber /chat/api/qms/.
• Signatur: Tabelle email_signatures in auth.db. ID __global__ = Firmen-Signatur, ID = user_id = individuelle Signatur.

Einkauf-Dashboard

Das Einkauf-Dashboard unter /einkauf/ ist das Eingangsmodul fuer Wareneingang, Chargen und Lieferantenmanagement. Es folgt dem Standard-Design-System mit Apple Glasmorphism, Dark/Light Mode und eingebettetem RUDI Chat-Panel.

Wareneingang

Vollstaendige Seite unter /einkauf/wareneingang.html. Erfassung und Pruefung von Wareneingaengen mit Lieferant, Charge, Typ (Bio/Standard/Packaging) und Status-Workflow (neu → geprueft → eingelagert / abgelehnt). Includes Accordion-Liste, Erfassungs-Modal mit Drag&Drop-Bild-Upload, client-seitiger Bild-Komprimierung (max 2560×1440, 85% JPEG), Duplikat-Check fuer Chargen, LocalStorage-Autosave und Excel-Export.

Phase-3-Erweiterungen (2026-04-27): Country-of-Origin-Pflichtfeld (Feature-Flag we_country_pflicht) mit Dropdown (30 Laender), Auto-Vorbefuellung via GET /vorbereiten nach Lieferant-Auswahl · Quelle-Badge zeigt ob Country aus Avis, Lieferanten-Default oder manuell · Vorgang-Info-Box: zeigt offene Vorgaenge, Dropdown bei mehreren, "Neuer Vorgang" wenn keiner · Avis-Positionen-Box (collapsible): "Alle uebernehmen" matcht Rohwaren automatisch · Vision-Live-Warnung: nach Bild-Upload Polling alle 5s, gelbe/rote Box bei Maengeln (Feature-Flag we_vision_warnung) · Quality-Filter Dropdown (Alle/OK/Mangel/Gesperrt) · Quality-Badge als neue Spalte in der Liste · capture="environment" fuer direkten Smartphone-Kamera-Aufruf.

Features: Filter nach Typ/Status/Quality/Datum/Suche · Thumbnails mit Lightbox · RUDI Chat-Panel (Modul: einkauf) · Detail-Link zu /einkauf/detail.html?id=X

Wareneingang Detail

Detailseite /einkauf/detail.html?id=X mit 2-Spalten-Layout (Main + 340px Sidebar). Laedt Daten von GET /chat/api/einkauf/wareneingang/{id}.

Main-Bereich: Stammdaten-Card (Lieferant, Datum, Typ, Status) · Daten-Card (Charge, Rohwaren als Chips, Notizen) · Bilder-Galerie mit Tabs (Lieferscheine / Waren), Thumbnail-Grid, Lightbox · Direkter Bild-Upload je Tab · KI-Bildanalyse-Card (MIB-Audit Korrektur 4, 2026-04-28): Pro Bild Thumbnail + vision_beschreibung aus wareneingang_bilder + Vision-Status-Badge (done/pending/error). Bei pending: Spinner "Analyse laeuft...". Bei error: graue Box + "Erneut versuchen"-Button (POST /quality-check). Zusammenfassungs-Zeile (X analysiert, Y ausstehend, Z Fehler). Button "Neu analysieren" fuer alle Bilder. Kein Backend-Change noetig: SELECT * liefert bereits vision_status + vision_beschreibung. · OCR-Text-Section (collapsible).

Sidebar (Phase 3): Lieferanten-Info · Chargen-Info · Herkunftsland-Card · Quality-Pruefung-Card: Status-Badge, Maengel-Liste, Button "Neu analysieren" (POST /quality-check), nur sichtbar wenn Feature-Flag we_vision_warnung ON · Vorgang-Card: Vorgang-ID als Link, Belege-Typen-Uebersicht · Soll-Ist-Vergleich-Card (Phase 4 Vorbereitung): bei vorhandener Vorgang-ID ladbar via GET /vorbereiten · Zeitstempel · Sync-Badge.

Edit-Modal (Phase 3 ergaenzt): Herkunftsland-Dropdown (30 Laender) · Herkunftsland wird bei PUT /wareneingang/{id} als herkunftsland_iso mitgesendet.

API-Calls der Detailseite: GET /wareneingang/{id}, PUT /wareneingang/{id} (Edit + Status + herkunftsland_iso), DELETE /wareneingang/{id}, POST /wareneingang/{id}/bilder, DELETE /wareneingang/{id}/bilder/{bildId}, POST /wareneingang/{id}/quality-check (Phase 3)

API-Pfade (alle ueber /chat/api/einkauf/):

Vorgangsmodell – Phase 4: Auto-Reklamation Solvega (Schatten-Modus)

Automatische Soll/Ist-Diff-Detektion mit Claude Vision fuer Lieferanten-Handschrifterkennung auf Albarane. 4-Wochen-Schatten-Modus: Vorschlaege landen in DB, kein Mail-Versand. Mensch gibt frei.

Solvega-Spezifik: Vereinbarung Regio Frucht ↔ Solvega: Regio Frucht wiegt jede Lieferung, teilt Ist-Mengen mit, Solvega korrigiert die Rechnung entsprechend. Mengen werden handschriftlich auf das Albaran notiert. Vision liest Soll (gedruckt) + Ist (Handschrift) automatisch.

Neue Dateien:

• ~/rudi-chat/lib/vision-handschrift.js — Claude Sonnet Vision fuer handschriftliche Mengen-Notizen. API: extractHandschriftMengen(imagePath, opts). Tagesbudget: VISION_HANDSCHRIFT_MAX (default 100 = max ~$0.50/Tag). Robuster JSON-Parser + Regex-Fallback.
• ~/rudi-chat/lib/reklamations-generator.js — Claude Haiku Textgenerierung fuer Reklamationsschreiben. Few-Shot aus historischen Reklamationen. API: generiereReklamationsText({lieferant_name, artikel, soll, ist, diff_kg, diff_pct, preis_pro_einheit}).
• ~/bin/soll-ist-diff-trigger.js — Cron alle 30 Min. Sucht Kandidaten-WEs (7 Tage, kein bestehender Auto-Vorschlag), ruft Vision auf Lieferschein-Bilder auf, berechnet Diff > 2%, speichert Vorschlag in reklamationen + Cockpit-Eintrag + Audit-Log.
• ~/bin/rechnung-korrektur-check.js — Cron stündlich. Vergleicht eingehende Solvega-Rechnungen mit gemeldeter Ist-Menge. Setzt freigabe_status auf 'nicht_noetig' (Solvega hat korrigiert) oder 'dringend' (nicht korrigiert).

Feature-Flags: auto_reklamation_solvega (ON = Schatten-Modus) · auto_reklamation_versand (OFF = kein Auto-Versand)

Cron-Datei: /etc/cron.d/auto-reklamation (30 Min Diff-Trigger + 60 Min Rechnung-Check)

Log-Dateien: ~/backups/auto-reklamation.log, ~/backups/rechnung-korrektur.log

Env-Konfiguration: AUTO_REKL_LIEFERANTEN (Komma-Liste), AUTO_REKL_DIFF_PCT (default 2.0), AUTO_REKL_KRITISCH_PCT (default 10.0), VISION_HANDSCHRIFT_MAX (default 100/Tag)

DB-Felder: reklamationen.auto_erstellt=1, .freigabe_status='vorgeschlagen', .ki_vorschlag_json (vision_konfidenz, vorschlag_text, gutschrift_berechnung). cockpit_auffaelligkeiten.typ='gewichtsdiff', .schweregrad='warn'|'kritisch'.

Score-Gate: 4 Wochen Schatten-Modus, mind. 40 Vorschlaege, davon ≥90% akzeptiert → dann Auto-Versand aktivierbar via auto_reklamation_versand=ON

Vorgangsmodell – Phase 4: Lieferanten-Risiko-Score (woechentlich)

Woechentliche automatische Risiko-Bewertung aller aktiven Lieferanten mit Wareneingaengen in den letzten 90 Tagen. Score-Berechnung aus drei Komponenten: Reklamationsquote (50%), Mengen-Abweichungsquote (30%), Vision-Maengel-Quote (20%). Trend-Berechnung (besser/stabil/schlechter) aus Vergleich aktueller 90 Tage vs. vorangehende 90 Tage.

Score-Logik: base_score = (rek_pct * 0.5) + (diff_pct * 0.3) + (vision_pct * 0.2). Kategorie: ≥30 = rot, ≥10 = gelb, sonst gruen.

Neue Dateien:

• ~/bin/lieferanten-risiko-score.js — Cron Mo 04:00 UTC. Berechnet Risiko-Score fuer alle Lieferanten mit >0 WE in 90 Tagen. Schema-Migration idempotent. Schreibt in lieferanten.risiko_score/risiko_kategorie/risiko_komponenten_json/risiko_trend/risiko_aktualisiert_am.

DB-Schema-Erweiterung (einkauf.db Tabelle lieferanten):

• risiko_score INTEGER — 0-100
• risiko_kategorie TEXT — gruen | gelb | rot
• risiko_komponenten_json TEXT — JSON {wes_90, reks_90, quote_rek_pct, wes_mit_diff_90, quote_diff_pct, wes_mit_vision_mangel_90, quote_vision_pct, prev_score}
• risiko_trend TEXT — neu | besser | stabil | schlechter
• risiko_aktualisiert_am TEXT — ISO-Timestamp des letzten Laufs

Cron-Datei: /etc/cron.d/lieferanten-risiko-score (Mo 04:00 UTC)

Log-Datei: ~/backups/lieferanten-risiko-score.log

Audit-Log: modul=lieferanten-risiko, aktion=woechentlich, after_json={count_rot, count_gelb, count_gruen, top_3_rot, ergebnisse[{id, name, score, kategorie, trend}]}

Briefing-Integration: ~/rudi-chat/lib/briefing.js — build() gibt jetzt einkauf.risiko_lieferanten (rot, max 5), einkauf.top_auffaelligkeiten (offen, max 3), einkauf.offene_rek_vorschlaege (Anzahl auto_erstellt+vorgeschlagen) zurueck. formatRisikoText(einkauf) erzeugt lesbaren Warntext fuer Voice/Chat.

REST-Endpoints:

Aktuell (2026-04-27): Solvega Crops = rot (Score 46.9, Rek-Quote 93.8%) · Kraaijeveld BV = gelb (Score 17.8) · GP green produce = gelb (Score 13.6) · Schwehr Georg = kein Score (keine WE in 90 Tagen, implizit gruen)

Vorgangsmodell – Phase 4: Mensch-in-the-Loop UI (Reklamations-Vorschlaege)

Frontend fuer die Pruefung und Freigabe automatisch erzeugter Reklamations-Vorschlaege (Cron alle 30 Min, bin/soll-ist-diff-trigger.js). Seite: /einkauf/reklamationen/.

Features: 4 Tabs (Vorschlaege/Freigegeben/Abgelehnt/Manuell) · Statistik-Kacheln (offene Vorschlaege, ausstehende Gutschriften, rote Lieferanten, letzter Cron-Lauf) · Detail-Modal mit Vision-Beschreibung, editierbarem Vorschlagstext und Gutschrift-Betrag · Freigeben-Button (gruen/grau je nach Feature-Flag) · Ablehnen mit Pflicht-Grund · Risiko-Badge inline bei Lieferant · Konfidenz-Balken · Chat-Sidepanel.

Neue Backend-Endpoints (in routes/einkauf.js):

Schatten-Modus: Feature-Flag auto_reklamation_versand = false (Standard). Bei Freigabe wird Status gesetzt, aber keine Mail versendet. Freigeben-Button zeigt "(Schatten-Modus aktiv)" und ist grau statt gruen.

Dateien: /var/www/html/einkauf/reklamationen/index.html, index.css, index.js

Vorgangsmodell – Phase 4: Risiko-Dashboard UI

Frontend fuer die Uebersicht des Lieferanten-Risiko-Scores. Seite: /einkauf/risiko/.

Features: 3 Ampel-Kacheln (rot/gelb/gruen, klickbar als Filter) · Tabelle aller Lieferanten sortiert nach Score · Mini-Bar-Charts inline fuer Rek-Quote, Diff-Quote, Vision-Mangel · Trend-Pfeil · Detail-Modal mit Score-Verlauf aus Audit-Log · Direkt-Link zu Reklamationen des Lieferanten · Chat-Sidepanel.

Dateien: /var/www/html/einkauf/risiko/index.html, index.css, index.js

Einkauf-Index ergaenzt: Zwei neue Kacheln "KI-Vorschlaege" und "Lieferanten-Risiko" mit animiertem Badge (rot wenn Vorschlaege offen / rote Lieferanten vorhanden).

Einkauf – Avis-Pipeline

Seite /einkauf/avis.html — Verwaltung avisierter Wareneingaenge. Zeigt alle vorab gemeldeten Lieferungen mit Status-Workflow (avisiert → geliefert → geprueft) und Soll/Ist-Abgleich.

Features: Stat-Kacheln (Gesamt/Geliefert/Geprueft/Abweichungen, interaktiv als Filter) · Status-Filter-Buttons · Lieferant-Dropdown-Filter · Datumsbereich-Filter (Standard: letzte 30 Tage) · Klick auf Zeile → /einkauf/avis-detail.html?id=X · Modal "Neues Avis" mit Lieferant-Dropdown, Datum und dynamischer Positionen-Tabelle · Ampel-Zusammenfassung (gruen=OK, orange=Warnung, rot=Fehler) · Status-Badges (avisiert=gelb, geliefert=blau, geprueft=gruen) · RUDI Chat-Panel (Modul: einkauf) · escHtml XSS-Schutz · Toast-System

API-Pfade (alle ueber /chat/api/einkauf/):

Einkauf – Lieferanten-Konfiguration

Seite /einkauf/lieferanten-config.html — Avis-Einstellungen und Artikel-Cross-Reference pro Lieferant. Accordion-Liste aller Lieferanten mit Inline-Konfiguration und Cross-Reference-Tabelle pro Lieferant.

Features: Stat-Kacheln (Gesamt/Aktiv/Verwogen/Cross-Refs) · Suche + Filter (Alle/Aktiv/Inaktiv) · Accordion-Details mit zwei Tabs (Konfiguration + Cross-Reference) · Quick-Toggle Avis aktiv/inaktiv direkt in der Listenzeile · Formular-Felder: avis_aktiv, gewichts_logik, toleranz_gewicht_prozent, toleranz_preis_prozent, referenz_dokumente · Expliziter Speichern-Button (kein Auto-Save) · Cross-Reference-Tabelle: Lieferant-Bezeichnung ↔ Interne Rohware ↔ Einheit ↔ Umrechnungsfaktor · Inline-Hinzufuegen neuer Cross-Refs · Loeschen mit Bestaetigung · RUDI Chat-Panel (Modul: einkauf) · escHtml XSS-Schutz · Toast-System

API-Pfade:

Chargen-Verwaltung

Seite /einkauf/chargen.html — Tages- und Wochenansicht der Rohwaren-Chargen. Tag-Navigation, collapsible Kategorie-Gruppen, klickbare Zellen zum Bearbeiten (Modal), Farbkodierung nach Herkunft (Lieferung / Manuell), Suche ueber API + lokales Highlight, Excel- und PDF-Export.

Features: Tag/Woche-Ansicht · Datum-Navigation (Vor/Zurueck/Heute) · Bis zu 10 Zaehlung-Spalten (dynamisch erweiterbar) · Edit-Modal mit Past-Date-Warnung · Statistik-Kacheln (Gesamt/Befuellt/Offen/Vollstaendigkeit) · RUDI Chat-Panel (Modul: einkauf) · Excel-Export (SheetJS, nach Kategorie gruppiert) · PDF-Export (jsPDF + AutoTable, A4 Quer)

API-Pfade (alle ueber /chat/api/einkauf/chargen/):

Bestand / Inventur

Seite /einkauf/bestand.html — Tages- und Wocheninventur der Rohwaren-Bestaende. Tag/Woche-Toggle, Suchfeld (Komma-getrennte Mehrfachsuche mit Gelb-Highlight), Vortagsvergleich (Auge-Button), Vortag kopieren, Tag loeschen mit 60s-Undo, Mehrfachzeilen pro Rohware, Kategorie-Export-Modal.

Rohware-Typen: 4 Typen — standard (Rohwaren in kg), bio (Bio-Rohwaren), packaging (Verpackungen in Stueck), supplies (Hilfsstoffe & Sonstiges: Bleche, Koerbe, Rollwagen, Aufguss, Behandlungsmittel, Saftbinder). Gruppierung nach Kategorie (BIO-Rohwaren, Fruechte, Gemuese, Kraeuter, Salat, Verpackung & Hilfsstoffe, Sonstiges).

Features: Tag/Woche-Ansicht · Suchfeld (Rohware oder Charge, komma-separiert) · Vortagsvergleich (Auge-Icon, Vortag-Werte in klein/grau) · Vortag kopieren (nur wenn Tag leer) · Tag loeschen + Undo (60s) · + Zusatzzeilen pro Rohware (x zum Loeschen) · Alle auf-/zuklappen-Button · Kategorie-Auswahl beim Excel/PDF-Export · Datum-Navigation · Inline-Edit (Enter/Blur/Escape) · Auto-Berechnung (colli × kg_pro_colli, lief_colli × lief_kg_pro_colli) · Unterdeckungs-Warnung (rot) · Statistik-Kacheln · Summenzeile · RUDI Chat-Panel (Modul: einkauf)

API-Pfade (alle ueber /chat/api/einkauf/bestand/):

Einkauf – Kontrakte

Seite /einkauf/kontrakte.html — Verwaltung von Rahmenvertraegen mit Lieferanten. Stats-Kacheln (aktive Kontrakte, bald ablaufend, gesamt), sortierbare Tabelle mit Ablauf-Warnung (90 Tage), Glasmorphism-Modal zum Erstellen/Bearbeiten, Excel- und PDF-Export (A4 Quer).

Features: Filter nach Lieferant/Rohware/Suchtext/Nur-aktive · Ablauf-Badge (rot wenn < 90 Tage) · Abgelaufene Zeilen grau/durchgestrichen · Sortierung per Spalten-Header · RUDI Chat-Panel (Modul: einkauf) · Excel-Export (SheetJS) · PDF-Export (jsPDF + AutoTable, A4 Quer)

API-Pfade (alle ueber /chat/api/einkauf/):

Einkauf – Preislisten

Seite /einkauf/preislisten.html — Verwaltung und KI-gestuetzte Extraktion von Lieferanten-Preislisten. Upload per Drag&Drop (xlsx, xls, csv, pdf), KI-Analyse mit Fortschrittsanzeige, Mapping unbekannter Artikel auf Rohwaren per Dropdown.

Features: Stat-Kacheln (Aktiv/Entwurf/Archiviert/Letzte Aktualisierung – klickbar, filternd) · Upload-Karte mit Drag&Drop-Zone, Lieferant-Dropdown, Gueltig-ab-Datum · Fortschrittsbalken waehrend KI-Extraktion · Portal-Scraper-Status (wenn Portal-Quellen vorhanden) · Sortierbare Tabelle (Lieferant, Datei, Quelle-Badge, Positionen, Status, Datum, Aenderungen) · Detail-Modal mit Positionstabelle und Preisvergleich (gruen=guenstiger, rot=teurer) · Ungemappte Artikel gelb markiert mit Zuordnungs-Dropdown · "Aktivieren" und "Loeschen" nur fuer Entwuerfe · RUDI Chat-Panel (Modul: einkauf)

API-Pfade (alle ueber /chat/api/einkauf/):

Einkauf – Preisabweichungen

Seite /einkauf/preisabweichungen.html — Preisabweichungs-Dashboard: Uebersicht aller Abweichungen zwischen Soll- und Referenzpreis mit Ampel-Visualisierung (gruen/gelb/rot), Akzeptanz- und Reklamations-Workflow sowie Top-Lieferanten-Auswertung.

Features: 4 Stat-Kacheln (Offen, Rot/Dringend, Gelb/Pruefen, Offene Differenz EUR) als klickbare Filter · Filter-Bar: Lieferant, Datum von/bis, Status · Tabelle mit 10 Spalten, sortierbar, horizontales Scrollen auf Mobile · Ampel-Dot (gruen/gelb/rot) pro Zeile · Aktions-Buttons: Akzeptieren (nur offen), Reklamieren (nur offen), Notiz-Textarea pro Zeile · Batch-Button "Alle Bagatellen akzeptieren" · Top-Lieferanten-Karten mit Abweichungs-Balken · RUDI Chat-Panel (Modul: einkauf)

API-Pfade:

Einkauf – Preisanalyse

Seite /einkauf/preisanalyse.html — Preisanalyse-Dashboard mit Trendverlauf, Lieferantenvergleich und auto-generierten Einsparhinweisen. Chart.js-Liniendiagramm mit Zeitraum-Wahl (3M/6M/12M), Dark-Mode-optimierten Farben und EUR-Tooltip-Format.

Features: 4 Stat-Kacheln (Aktive Lieferanten, Rohwaren mit Preisen, Aenderungen letzter Monat, Einsparpotenziale) · Rohware-Dropdown (GET /rohwaren) · Preisverlauf-Chart (Chart.js lokal, /shared/chart.umd.min.js) mit einer Linie je Lieferant · Zeitraum-Buttons 3M/6M/12M · Lieferantenvergleich-Tabelle: Rang, Lieferant, Preis, Avg 12M, Trend-Pfeil, vs-Bester · Hinweise-Grid (gruen/orange/rot-Karten) · Export-Button (xlsx-Download) · RUDI Chat-Panel (Modul: einkauf)

API-Pfade (alle ueber /chat/api/einkauf/):

Einkauf – Bestellungen

Seite /einkauf/bestellungen.html — Kundenbestellungen erstellen und verwalten. Zwei Tabs: "Bestellung erstellen" (Einstellungen + Multi-Select-Artikel + Positionstabelle + Excel-Export) und "Bestellhistorie" (collapsible Cards, loeschbar).

Features: Bestelldatum (default: morgen) · Empfaenger + CC E-Mails · Multi-Select-Dropdown mit Suchfeld und Checkbox pro Rohware · Ausgewaehlte Artikel als Tags · Bestand-Daten (Bedarf/Einkauf) automatisch befuellt · Editierbare Mengen und Einheiten · Excel-Export (SheetJS, Dateiname Bestellung_DD-MM-YYYY.xlsx) · Bestellhistorie collapsible mit Loeschen-Button · RUDI Chat-Panel (Modul: einkauf)

API-Pfade (alle ueber /chat/api/einkauf/):

Einkauf – Stammdaten

Seite /einkauf/stammdaten.html — Verwaltung von Lieferanten, Rohwaren (Artikeln) und Kategorien. Drei Tabs, jeweils mit Suchfeld, Filtern, Tabelle und Glasmorphism-Modals zum Erstellen/Bearbeiten.

Features: Lieferanten (Name, E-Mail, Kontaktperson, Telefon, CRUD) · Rohwaren (Name, Kategorie, Typ: bio/standard/packaging/supplies, CRUD) · Typ-Badges (gruen=bio, cyan=standard, grau=packaging, braun=supplies) · Kategorien (CRUD, Loeschen mit Hinweis) · Kategorie-Dropdown synchronisiert zwischen Tab und Modal · Confirm-Dialog vor Loeschungen · Skeleton-Loader · RUDI Chat-Panel (Modul: einkauf)

API-Pfade (alle ueber /chat/api/einkauf/):

Vorgangsmodell – Phase 1 (Datenmodell & Migration)

Das zentrale Vorgangsmodell klamert alle Beschaffungsbelege (Bestellung → Avis → Wareneingang → Reklamation → Rechnung → Gutschrift) in einer einzigen vorgang-Tabelle. Phase 1 legt das Datenbankschema an und backfilled alle bestehenden Wareneingaenge (1770 Stk.), Reklamationen (144 Stk.) und Rechnungen.

Neue Tabellen in ~/einkauf/einkauf.db:

Neue Spalten (ALTER TABLE, bestehende Daten unveraendert): wareneingaenge.vorgang_id, .herkunftsland_iso, .quality_status, .auto_validierung_json · we_positionen.soll_menge_quelle, .abweichung_kategorie · reklamationen.vorgang_id, .auto_erstellt, .ki_vorschlag_json, .freigabe_status · cockpit_auffaelligkeiten.vorgang_id, .claude_kommentar

View: vorgang_uebersicht — Joined-View mit Lieferant-Name und Beleg-Zaehler (WE/Reks/Rechnungen/Bestellungen).

DB-Layer:

Migration-Skripte:

Backfill-Ergebnisse (2026-04-27): 1770 WE-Vorgaenge · 144 Reklamationen verlinkt · 25 Rechnungen an WE-Vorgaenge · 744 neue Rechnungs-Vorgaenge (verrechnet) · 0 WE ohne vorgang_id

Hinweis: Phase 1 legt das Datenmodell an. API-Routes fuer Bestellungen: Phase 2 (routes/bestellung.js). Feature-Flag vorgang_anzeige steuert Frontend-Sichtbarkeit.

Migration 002 – Backfill-Cleanup (2026-04-28, Korrektur 3 mib-logik-Audit)

Phase-1 hatte fuer jede Rechnung ohne eindeutigen WE-Match einen eigenen Vorgang angelegt. Ergebnis: 746 "Rechnung-ohne-WE"-Vorgaenge (30% Datenmüll). Migration 002 bereinigt das idempotent in 3 Stufen:

• Stufe A: Match-Versuch (strikt via lieferschein_nr/chargennummer + loose via +/-14 Tage). 2 Merges gefunden, 677 uneindeutig (zu viele Lieferanten-WEs im Fenster), 65 ohne Treffer.
• Stufe B: Status-Markierung: status='nur_rechnung' (65) und status='nur_rechnung_uneindeutig' (677). Neue Spalte vorgang.notiz fuer Match-Hinweise.
• Stufe C: View vorgang_uebersicht neu — filtert nur_rechnung* heraus, zeigt nur operative Vorgaenge (1771). Neue Spalte kategorie (vollstaendig|nur_we|nur_rechnung|nur_rechnung_uneindeutig|leer). Separate View vorgang_uebersicht_nur_rechnung fuer die 742 verbleibenden.

Ergebnis (2026-04-28): 2516 → 2513 Vorgaenge · Operational: 1771 · Nur-Rechnung: 742 (aus Listen rausgefiltert) · 1 Leervorgang geloescht

Vorgangsmodell – Phase 2: Bestellungs-Erfassung

Backend-Route ~/rudi-chat/routes/bestellung.js, gemountet als /chat/api/bestellung. Alle Endpunkte benoetigen requireAuth + requireModule('einkauf'). Schreib-Endpunkte zusaetzlich requireWrite + requireCsrf. Audit-Log bei jeder Mutation (modul='bestellung').

Feature-Flag: bestellung_voice (Default: OFF) — Voice-Endpoint gibt 403 wenn deaktiviert.

Claude-Tools (Chat):

Handler-Dateien: ~/rudi-chat/routes/bestellung.js · ~/rudi-chat/lib/tools/handlers/bestellung.js · multer-secure.js um Audio-Preset erweitert (wav/mp3/m4a/webm/ogg)

Multer Audio-Preset: max 25 MB, Magic-Bytes-Check (WAV/MP3/OGG/WebM/M4A), kein EXIF-Strip (Audio hat kein EXIF). Destination: ~/uploads/voice-bestellung/

Frontend Bestellungs-Erfassung (Phase 2 UI)

Ziel: Telefonbestellungen in <30 Sekunden erfassen. Mobile-first, 375px-tauglich, Touch-Targets ≥36px, Apple Glasmorphism.

Feature-Flag bestellung_voice (Default OFF): Wenn aus → Voice-Modus-Card in Schritt 2 versteckt, Voice-Sektion in Detail-Seite ausgeblendet. Schaltbar in /admin/feature-flags.

Kachel in Einkauf-Dashboard: "Bestellung erfassen" (/einkauf/index.html) verlinkt direkt auf /einkauf/bestellung/neu.html (hervorgehoben in Accent-Farbe).

Dateien: /var/www/html/einkauf/bestellung/ (index.html, index.js, neu.html, neu.js, detail.html, detail.js, bestellung.css)

Produktionsplanung

Rohwaren-Bedarfsberechnung aus OData-Sync + Stücklisten. Datenbank: ~/produktionsplanung/produktionsplanung.db.

Prognose-Endpunkte

KI-gestuetztes Lernmodell (EWMA) fuer 14-Tage-Rohwaren-Prognose. Externe Faktoren: Wetter (Open-Meteo, Freiburg), Schulferien + Feiertage BW. Modell-Faktoren werden nach jedem OData-Sync automatisch aktualisiert.

System

Feature-Flag-System

Zentrale Laufzeit-Schalter fuer RUDI-Features. Kein Code-Aenderung, kein Service-Restart noetig. DB: ~/feature-flags/flags.db (eigene SQLite, WAL-Mode). Cache-Reload alle 30 Sekunden. Jede Aenderung wird in flags_history auditiert.

Aktuelle Flags (Phase-0-Matrix)

API-Endpunkte (Feature Flags)

Zentrales Audit-Log (Phase 0)

FSMA-204 / EU-Lebensmittelrueckverfolgung konformes Audit-Log. Eigenstaendige SQLite-DB ~/audit/audit.db (WAL, append-only via SQL-Trigger). Jede Datenänderung an Vorgangs-relevanten Daten wird unveraenderlich geloggt.

Backend: ~/rudi-chat/lib/audit.js | Route: ~/rudi-chat/routes/admin-audit.js | Mount: /chat/api/admin/audit

Append-only: SQL-Trigger blockieren UPDATE + DELETE auf der log-Tabelle (SQLite RAISE ABORT). Cloud-Backup: ~/bin/cloud-sync.sh databases (alle 2h direkt aus ~/audit/audit.db).

Bolt-Migration-Dashboard (Phase 6 Vorgangsmodell)

Backend: ~/rudi-chat/routes/admin-bolt.js | Mount: /chat/api/admin/bolt-diff | Frontend: /admin/bolt-migration.html

Taeglicher Drift-Report zwischen bolt.new (Firebase) und RUDI fuer die drei Hauptkacheln: Bestand, Wareneingang, Reklamation. 4-Wochen-Parallelbetrieb mit Empfehlung fuer Umschaltung.

Cron: /etc/cron.d/bolt-diff-report — taeglich 03:00 UTC. Skript: ~/bin/bolt-diff-report.js. Output: ~/backups/bolt-diff/YYYY-MM-DD.json. Audit-Eintrag: modul=bolt-migration, aktion=diff_report.

Schwelle: 0.5% Drift je Kachel. Empfehlung BOLT_READONLY_OK wenn 7 Tage am Stueck alle Kacheln darunter. "Bolt auf Read-Only"-Button in Frontend setzt Feature-Flag bolt_sync_active=OFF (nur manuell, nie automatisch).

workflow-audit.js prueft taeglich ob letzter Bericht juenger als 36h ist und ob Drift-Schwelle ueberschritten.

Vorgangsmodell – Phase 7: Compliance & Claude-Briefing-Layer (2026-04-28)

FSMA-204-Compliance-Automatisierung + Lieferanten-Zertifikat-Management + vorgang_analyse-Tool fuer RUDI-Chat.

1. Recall-Drill aktiviert

Cron /etc/cron.d/recall-drill ist seit 2026-04-28 aktiv (Mo 06:00 UTC, vorher auskommentiert). Feature-Flag recall_drill_cron auf ON gesetzt. Skript: ~/bin/recall-drill.js. Log: ~/backups/recall-drill.log. CLI: --random | --charge <nr> | --we-id <id> | --json.

2. Lieferanten-Zertifikate

Frontend: /einkauf/zertifikate/index.html — Tabelle aller Zertifikate, Filter (alle/ablaufend/abgelaufen), + Neu / Edit-Modal / Loeschen. Rollen: requireAuth + requireModule('einkauf').

Cron: /etc/cron.d/zertifikat-erinnerung — taeglich 05:00 UTC. Skript: ~/bin/zertifikat-erinnerung.js. Prueft lieferant_zertifikat mit erinnerung_aktiv=1. Legt Cockpit-Eintraege typ='zertifikat_ablauf' an (warn = ablaufend, kritisch = abgelaufen). Duplikat-Schutz per UNIQUE-Check. Log: ~/backups/zertifikat-erinnerung.log.

3. Tool vorgang_analyse

Neues RUDI-Chat-Tool (definitions.js + handlers/vorgang.js). Eingabe: vorgang_id ODER charge ODER we_id. Ausgabe: strukturierter Text mit Stammdaten, Beleg-Kette, Mengenvergleich, Reklamationen, Bilder/Vision, Lieferanten-Risiko-Score, Vollstaendigkeits-Score (0-1), FSMA-4h-Bewertung.

4. Briefing-Erweiterung (Phase 7)

briefing.js gibt jetzt compliance: { recall_drill_letzte, bolt_diff_status, zertifikate_ablaufend } zurueck. formatComplianceText() formatiert als lesbaren Text fuer Voice/Chat. shortSummary() erwaehnt ablaufende Zertifikate. Neue Exports: getRecallDrillLetzteErgebnisse(n), getBoltDiffStatus(), getZertifikateAblaufend(tage).

5. workflow-audit.js — checkZertifikate()

Neuer Check: prueft abgelaufene Zertifikate (→ kritisch) und in 14 Tagen ablaufende (→ warn). Laeuft im taegl. Workflow-Audit-Cron (04:00 UTC).

Backend-API (lib/audit.js)

Sensible Felder (password, password_hash, pin, api_key, token, secret etc.) werden vor dem Speichern automatisch durch [REDACTED] ersetzt. before/after-Felder auf max. 50 KB begrenzt (Truncation-Hinweis bei Ueberschreitung).

Backend-Modul (lib/feature-flags.js)

Phase-0-Sicherheitsbausteine

Drei Sicherheitsmodule, die als Fundament fuer DSGVO-konforme Uploads und HMAC-gesicherte Webhook-Integrationen dienen. Hinzugefuegt 2026-04-27.

EXIF-Stripper (lib/exif-strip.js)

Entfernt EXIF-Metadaten (GPS, Kamera-Daten, Timestamps) aus Bild-Uploads. Verhindert DSGVO-Risiko bei Reklamations-/Wareneingangs-Fotos mit Mitarbeiter-Bezug (Geo-Koordinaten). Nutzt sharp().rotate() ohne withMetadata() — atomarer Datei-Tausch via tmp-Datei.

Gehaerteter Multer-Helper (lib/multer-secure.js)

Factory fuer gehaertete Multer-Instanzen. Ersetzt direkte multer()-Aufrufe in Routen. Integriert: Mime-Whitelist, Magic-Bytes-Check (defense-in-depth gegen MIME-Spoofing), EXIF-Stripping, File-Size-Limit 25 MB. Feature-Flag upload_hardening schaltet gehaertete Pipeline ein (ON = Default) oder zurueck auf Legacy.

Mime-Presets: 'image' (JPEG/PNG/WebP/HEIC/HEIF), 'document' (PDF + Bilder), 'mixed' (alle). Magic-Bytes werden aus den ersten 12 Bytes der Datei gelesen — keine externe NPM-Abhaengigkeit.

Aktuell genutzt: routes/einkauf.js — Wareneingang-Bild-Upload (WE-Fotos + Lieferschein-Scans).

HMAC-Middleware (lib/hmac-middleware.js)

Signaturpruefung fuer kuenftige Webhook-Endpunkte von Lieferanten-Portalen (Push-Avis). Kein Session-Cookie, kein CSRF. Auth via HMAC-SHA256 ueber timestamp + '\n' + rawBody. Clock-Skew-Pruefung (default 5 Min) verhindert Replay-Angriffe. crypto.timingSafeEqual verhindert Timing-Angriffe. Secrets werden nie geloggt.

Mount-Reihenfolge: Webhook-Router MUSS vor express.json() gemountet werden (raw body muss unverbraucht sein). In server.js am Anfang, vor globalem Body-Parser.

Test-Endpunkt: POST /chat/api/hooks/test — HMAC-Secret: 'test-shared-secret'. Fuer Produktion: env:WEBHOOK_SECRET_LIEFERANTNAME in /etc/environment.

Webhook-Route-Gruppe (routes/hooks-example.js)

Gemountet als /api/hooks/* VOR globalem Auth. Neue Lieferanten-Webhooks werden hier als zusaetzliche router.post()-Eintraege angelegt.

Test-Suite & Self-Improvement

RUDI hat ein automatisches Test- und Lernsystem. Jeder gemeldete Bug fuehrt zu einem Fix, einem neuen Test und einer gelernten Regel — damit der gleiche Fehler nie wieder auftritt.

Master-Testrunner

Ergebnis: ~/rudi-chat/test-results.json (JSON), Exit-Code 0 = bestanden, 1 = Fehler.

Layout-Tests (15 Seiten)

Getestete Seiten: Dashboard, QMS, Aufgaben, Reklamation, Dateien, System, Pipeline, Maschinen, Maschine-Detail, Vorschlaege, Vorschlag-Detail, Notfall, Notfall-Druck, Doku, Chat.

Checks pro Seite:

• Layout: Overflow, Text-Truncation, Navigation, versteckte Panels
• Fehler: JS-Fehler, Resource-404s
• Bilder: Alle sichtbaren <img> geladen (naturalWidth > 0)
• Buttons: Korrekte Groesse (min 20×20px)
• Eingabefelder: Korrekte Groesse (min 50px breit, 20px hoch)
• API-Daten: Seiten mit Daten rendern mindestens 1 Datensatz
• Seitenspezifisch: Formulare, Thumbnails, Tabs, Galerien etc.
• Custom-Checks: Aus ~/rudi-chat/test-checks.json

Screenshots: ~/layout-tests/

/bugfix Skill — Self-Improvement-Loop

Der /bugfix Skill ist der Kern des Lernsystems. Er wird automatisch aktiviert wenn der User ein Problem beschreibt:

• „funktioniert nicht“, „ist kaputt“, „wird nicht angezeigt“
• „hier ist ein Fehler“, „das stimmt nicht“
• „habe etwas entdeckt was nicht korrekt funktioniert“
• „Bild laedt nicht“, „Button geht nicht“, „Seite zeigt nichts an“
• Oder jede andere Beschreibung eines Fehlverhaltens

Der Skill fuehrt automatisch 5 Schritte durch:

1. Analyse: Betroffene Datei lesen, Root-Cause finden
2. Fix: Minimaler, gezielter Fix implementieren
3. Test: Neuen Check in test-checks.json hinzufuegen (Regressions-Test)
4. Memory: Feedback-Datei schreiben (alle Agents lernen daraus)
5. Verifikation: node ~/bin/rudi-test.js ausfuehren

Deploy-Gate

Der /deploy Skill fuehrt vor jedem Deployment node ~/bin/rudi-test.js aus. Bei Fehlern wird das Deployment gestoppt.

Skills & Agents

MIB-Team (Men in Black)

Automatisiertes Sicherheits- und Qualitaets-Audit durch 4 parallele Spezialisten-Agents.

Manuell starten: Im Chat sagen: Lasse die Men in Black ausruecken oder /mib-audit

Automatisch: Jeden Sonntag um 03:00 UTC via Cron-Job (~/bin/mib-audit.sh)

Berichte: ~/rudi-chat/audit-log.json (Score-Historie mit Trend)

Score-Berechnung: Security × 0.35 + Backend × 0.25 + Frontend × 0.20 + Doku × 0.20

Hintergrund-Jobs (Cron)

Wichtige Dateien (Testing)

Server-Setup

Nginx-Konfiguration

• TLS: Nur TLS 1.2 + 1.3
• HSTS: 1 Jahr + includeSubDomains
• Basic Auth: Global auf allen Routen
• Rate Limiting: 10 Req/Min pro IP auf Chat-API (Burst 5)
• Security Headers: X-Frame-Options, X-Content-Type-Options, XSS-Protection, Referrer-Policy, Permissions-Policy
• Max Upload: 200 MB fuer QMS, 50 MB fuer Chat-Uploads
• Proxy Timeouts: 300s Chat (SSE), 120s QMS, 60s Transcribe

Sicherheit

Versionierung & Rollback

Alle Code-Verzeichnisse sind mit Git versioniert. Vor jeder Aenderung wird committed – so kann jeder Stand wiederhergestellt werden.

Git-Repositories

Die .gitignore schliesst automatisch aus: node_modules/, chat-history/, qms-annotations.json, qms-recurring.json, Backups und Logs.

Aenderungen sichern

# Status pruefen (welche Dateien geaendert?)
cd ~/rudi-chat && git status

# Aenderungen ansehen
git diff

# Commit erstellen (vor weiteren Aenderungen!)
git add -A && git commit -m "Beschreibung der Aenderung"

Rollback: Code zuruecksetzen

# Einzelne Datei zuruecksetzen
git checkout -- server.js

# ALLE Aenderungen verwerfen (zurueck zum letzten Commit)
git checkout .

# Zu einem bestimmten Commit zurueckspringen
git log --oneline          # Commits auflisten
git checkout abc1234 .     # Alles auf Stand abc1234 setzen

# Letzten Commit rueckgaengig machen (Aenderungen bleiben als unstaged)
git revert HEAD

Nginx-Backup

Nginx-Config ist kein Git-Repo (liegt unter /etc/). Dafuer gibt es ein Backup-Skript:

# Backup erstellen (vor Nginx-Aenderungen!)
~/bin/backup-nginx.sh "beschreibung"

# Backups auflisten
ls ~/backups/nginx/

# Zuruecksetzen
sudo cp ~/backups/nginx/nginx-XXXXXX.conf /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

Es werden automatisch die letzten 20 Backups behalten, aeltere werden geloescht.

System-Status pruefen

# Gesamtstatus: Git-Stand aller Repos + Services
~/bin/rudi-status.sh

Zeigt fuer jedes Repo den letzten Commit, ob ungesicherte Aenderungen vorliegen, Nginx-Backups und den Service-Status.

Wartung

Service-Befehle

# Backend neustarten
sudo systemctl restart rudi-chat

# Logs anzeigen
sudo journalctl -u rudi-chat -f

# Nginx pruefen & laden
sudo nginx -t && sudo systemctl reload nginx

# Pipeline neustarten
sudo systemctl restart regio-pipeline
sudo journalctl -u regio-pipeline -f

# Layout-Tests
node ~/bin/layout-test.js
node ~/bin/layout-test.js --mobile
node ~/bin/layout-test.js --verbose

# Tree.json aktualisieren
bash ~/bin/generate-tree.sh

# System-Status (Git + Services)
~/bin/rudi-status.sh

# Nginx-Backup erstellen
~/bin/backup-nginx.sh "beschreibung"

Wichtige Dateien