AI Stories

Aus der Praxis.

Echte Projekte. Echte Zahlen. Echte Ergebnisse.

05. März 2026 · Success Story · Full-Stack

Kundenportal v2 — Neuentwicklung in wenigen Stunden, 100 €/Monat gespart

Ein komplettes Kundenportal — Dashboard, Rechnungen mit PDF-Vorschau, filterbare Leistungsnachweise — ersetzt ein WordPress-Plugin und spart 100 €/Monat Betriebskosten.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6)
~4 h AI-Arbeitszeit
>16 h Manuelle Entwicklerzeit
3 Neue Seiten
6 Backend-Endpunkte
100 € Monatlich gespart
0 WordPress-Abhängigkeiten

Ausgangslage

WordPress-Portal am Limit

Das bestehende Kundenportal lief als WordPress-Plugin auf einem separaten Server mit eigener Datenbank-Anbindung. Kunden konnten nur Leistungsnachweise einsehen — keine Rechnungen. Die Lösung war technisch veraltet, wartungsintensiv und verursachte laufende Hosting-Kosten von rund 100 € pro Monat. Zusätzlich hängten sich die WordPress-Automatisierungen regelmäßig auf.

🔓

Keine echte Zugriffskontrolle

Dokument-Downloads waren nur durch URL-Verschleierung geschützt, nicht durch serverseitige Berechtigungsprüfungen.

🛠

Wartungsaufwand

PHP-Updates, WordPress-Core-Updates, Plugin-Kompatibilität — alles manuell.

🌐

Separate Infrastruktur

Eigener Server, eigene Datenbank-Verbindung, eigenes SSL-Zertifikat.

❌

Eingeschränkte Features

Kein Dashboard, keine PDF-Vorschau, kein responsives Design.

Prozess

1

Architektur & Backend-Endpunkte

~45 min

6 neue API-Endpunkte im bestehenden Azure Functions Stack. Jeder Zugriff wird serverseitig validiert — Customer-Portal-ID → Kundennummer-Mapping → Berechtigungsprüfung.

2

Sicherheitsmodell

~20 min

Drei Sicherheitsebenen: Token-Authentifizierung, Kundennummer-Mapping über Modul-Config, Dokument-Validierung vor jedem Download.

3

Flutter-Modul & Dashboard

~30 min

Dashboard mit QuickLink-Karten und KPI-Übersicht (Lieferungen der letzten 30 Tage, Rechnungssummen). Single-Client-Redirect direkt ins Portal.

4

Rechnungen mit PDF-Vorschau

~40 min

Master-Detail-Layout: Links die sortier- und suchbare Rechnungsliste, rechts die Inline-PDF-Vorschau. Download über Blob-URL statt Base64.

5

Leistungsnachweise mit Filtern

~30 min

Filterbare Tabelle mit Ort, Fahrer, Zeitraum. CSV-Export und Summenzeile. Alle Beträge mit € formatiert.

6

UI-Feinschliff & Bugfixes

~35 min

Sidebar-Highlighting, Summenzeilen-Styling, Header-Duplikat-Bug im REST-Client, PDF-Download von Data-URI auf Blob-URL umgestellt.

Was das neue Portal besser macht

WordPress (alt)
  • URL-basierte Sicherheit, keine Token-Auth
  • Nur Download, keine PDF-Vorschau
  • Kein Dashboard, kein Export
  • Separater Server (~100 €/Monat)
  • PHP, WordPress, Plugins — manuell gewartet
Flutter App (neu)
  • Bearer-Token + 3-stufige Prüfung
  • Inline-PDF-Preview + Download
  • Dashboard mit KPIs, CSV-Export, Filter
  • Im bestehenden Stack (0 € Mehrkosten)
  • Null Wartung — gleiche Codebasis wie Hauptapp

Erkenntnisse

🔒

Sicherheit muss kein Feature-Blocker sein

Drei Sicherheitsebenen implementiert und trotzdem mehr Features als vorher. Die Prüfungen laufen serverseitig in Millisekunden.

🏗

Bestehende Infrastruktur nutzen

Das WordPress-Portal existierte nur, weil es „schnell ging“. Die Integration in den bestehenden Stack dauerte wenige Stunden — und eliminiert dauerhaft Wartung und Kosten.

📄

PDF-Vorschau verändert den Workflow

Kunden müssen nicht mehr jede Rechnung herunterladen, um sie zu prüfen. Inline-Vorschau spart Zeit und reduziert Support-Anfragen.

🧩

Modularer Aufbau zahlt sich aus

Dank des bestehenden Modul-Systems (MenuBuilder, RoutingDefinition, DataGrid) war das UI in wenigen Stunden fertig.

🚀

Fazit

Ein komplettes Kundenportal — Backend mit 6 Endpunkten und dreistufigem Sicherheitsmodell, Frontend mit Dashboard, PDF-Vorschau und filterbaren Listen — in ~4 Stunden AI-Arbeitszeit. Mehr Features als das WordPress-Original, bessere Sicherheit, und 100 € pro Monat weniger Betriebskosten. Der separate WordPress-Server kann abgeschaltet werden.

04. März 2026 · Success Story · Web-Analyse & Optimierung

Website-Audit — 3 Websites, 4 Berichte, ~2 Stunden

Drei KMU-Webseiten auf WordPress, TYPO3 und statischem Hosting einem umfassenden Audit unterzogen: SEO, Performance, Sicherheit, Rechtliches, Design, Wettbewerbsvergleich — inklusive sofort umsetzbarer Verbesserungsvorschläge.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6)
~2 h AI-Arbeitszeit
>10 h Manuelle Expertenzeit
3 Websites analysiert
4 Analyse-Berichte
80+ Handlungsempfehlungen
10 Bewertungskategorien

Ausgangslage

Audit-Auftrag

Ein Beratungsunternehmen wollte für drei Geschäftspartner deren Webauftritte systematisch bewerten lassen: Schulnoten-Bewertung, kritischste Schwachstellen, Quick Wins mit maximalem Effekt und Wettbewerbsvergleich. Drei unterschiedliche Technologien (WordPress/Divi, TYPO3, statisch) — alle mit Optimierungspotenzial.

Der AI-gestützte Analyse-Prozess

1

Automatisierte Bestandsaufnahme

~15 min

Parallele Agenten erfassten alle drei Websites gleichzeitig: CMS-Version, Plugins, SEO-Baseline, Design-Analyse. Über 100 Einzelseiten inventarisiert.

2

Tiefenanalyse & Bewertung

~20 min

Jede Website in 10 Kategorien bewertet — mit Schulnote, Begründung und konkreten Handlungsempfehlungen. Von Gesamteindruck über SEO bis Barrierefreiheit.

3

Ladezeiten-Benchmark

~10 min

Performance-Messung gegen 2026-Standards: CMS-Seiten lagen 5–14x über dem empfohlenen TTFB-Wert. Die statische Site lag 2x unter dem Benchmark.

4

Wettbewerbsvergleich

~15 min

Parallele Recherche: Identifikation relevanter Wettbewerber, Vergleich der SEO-Sichtbarkeit, technischen Qualität und Content-Strategie.

5

Vergleichsreport & Priorisierung

~10 min

Alle drei Websites im Direktvergleich über 13 Kategorien. Querschnitt-Analyse, Ranking nach Handlungsdringlichkeit, Quick Wins vs. strategische Maßnahmen.

Quick Wins — der eigentliche Mehrwert

SEO Quick Wins

Title-Tags mit lokalen Keywords, individualisierte Meta-Descriptions, Schema.org JSON-LD ergänzen, XML-Sitemap generieren und einreichen.

Performance Quick Wins

Bilder in WebP konvertieren, Lazy-Loading aktivieren, CSS/JS minifizieren, Browser-Caching-Header setzen, ungenutzte CSS-Regeln entfernen.

Sicherheits Quick Wins

CMS-Versionen aktualisieren, Admin-Login-URLs ändern, Security-Header ergänzen (X-Frame-Options, CSP, HSTS), exponierte Benutzernamen deaktivieren.

Rechtliche Quick Wins

Impressum nach §5 TMG vervollständigen, Cookie-Consent korrekt implementieren, Datenschutzerklärung mit allen eingesetzten Diensten aktualisieren.

Erkenntnisse

🔍

SEO-Defizite sind universal

Alle analysierten Sites hatten grundlegende SEO-Mängel: generische Title-Tags, fehlende Schema.org-Markierung, keine lokale SEO-Strategie.

⚡

CMS-Overhead ist messbar

Die CMS-basierten Sites lieferten 5–14x langsamere Antwortzeiten als die statische Site. Das CMS ist oft die größte Performancebremse.

⚖

Rechtliche Mängel sind weit verbreitet

Fehlendes Impressum, unvollständige Datenschutzerklärungen — kaum eine Site war rechtlich einwandfrei. Ein oft unterschätztes Risiko.

🎯

Quick Wins haben den größten ROI

80% der Verbesserungen lassen sich mit 20% des Aufwands umsetzen: SEO-Meta-Tags, Bildoptimierung, Security-Header.

🚀

Proof-of-Concept überzeugt

Optimierte Gegenentwürfe als live deployte Websites zeigen nicht nur was verbessert werden sollte, sondern wie es aussieht wenn es umgesetzt ist.

📊

Fazit

In ~2 Stunden AI-Arbeitszeit entstanden 4 umfassende Analyse-Berichte mit über 80 konkreten Handlungsempfehlungen, Ladezeiten-Benchmarks, Wettbewerbsvergleiche und optimierte Gegenentwürfe als Proof-of-Concept — ein Arbeitsvolumen, das manuell mindestens 10+ Stunden Expertenzeit erfordert hätte. Der eigentliche Durchbruch: von der Analyse über konkrete Empfehlungen bis zum funktionierenden Proof-of-Concept in einem durchgängigen Workflow.

04. März 2026 · Success Story · Debugging & Feature-Fix

Email-Versand Fix — 6 Fehler über 3 Codebasen in 70 Minuten

Ein Agent analysiert einen abgestürzten Email-Workflow, findet 6 unabhängige Fehler über Backend, Frontend, Datenbank und API-Serialisierung hinweg — und löst sie in einer Session.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6)
~70 min AI-Arbeitszeit
>6 h Manuelle Entwicklerzeit
6+2 Fehler + Optimierungen
3 Codebasen (C#, Dart, SQL)
291 Transaktionen verifiziert
7 Dateien geändert/neu

Ausgangslage

Workflow-Absturz

Der automatisierte Email-Versand für einen Rechnungslauf mit ~1.600 Rechnungen brach nach 280 erfolgreich versendeten Emails ab. In der Flutter-App wurden im „Emails“-Tab keine Einträge angezeigt. Es war unklar, ob das Problem im Backend, Frontend oder in der Datenbank lag.

6 Fehler — 6 Fixes

1

Workflow-Absturz ohne Fehlerdetails

Durable Functions Orchestrator stürzte bei einem Einzelfehler komplett ab — kein Logging, keine Fortsetzung. Fix: Individuelle Fehlerbehandlung pro Rechnung mit strukturiertem Summary-Log.

2

Enum-Mismatch Backend/Frontend

Status-Werte für Email-Transaktionen waren im Flutter-Model anders definiert als im C#-Backend. Versendete Emails wurden als „Fehler“ angezeigt.

3

Emails-Tab lud keine Daten

Tab-Wechsel aktualisierte nur die URL, löste aber keinen API-Call aus. Zusätzlich verschluckte ein generischer catch (_) {} alle Fehler lautlos.

4

API-Serialisierung inkompatibel

Ein Endpoint verwendete PascalCase, alle anderen camelCase. Der Flutter-Mapper ist case-sensitiv — Response konnte nicht deserialisiert werden.

5

Fehlende BCC bei Sonderfällen

Rechnungen mit manuellem Versandweg gingen ohne BCC-Kopie raus — der Absender erhielt bei Sonderfällen keine Kontrollkopie.

6

Datenbank-Diskrepanz nach Abbruch

DB-Backup vor dem Versand erstellt — nach Abbruch fehlten Versand-Timestamps und Transaktionsdaten. Idempotentes SQL-Fixskript erstellt.

Methodik

Fehleranalyse Stack-Trace-Verfolgung über Orchestrator, Activity bis zum Service-Code
DB-Verifizierung SQL-Queries auf LocalDB, Kreuzvalidierung mit empfangenen Email-Kopien
API-Test Direkte Endpoint-Aufrufe, Vergleich der JSON-Response-Formate
Frontend-Tracing Tab-Controller → Lazy-Load → Mapper → API-Call-Chain
Differenzanalyse 270 empfangene Emails vs. 291 DB-Einträge nach Transport-Typ und Retry

Optimierungen

SMTP Rate-Limit-Erkennung

Strato SMTP drosselt bei zu vielen Emails. Bisher schlug jede folgende Email einzeln fehl. Jetzt: 6 bekannte Rate-Limit-Patterns werden erkannt, Versand bricht sofort ab, UI zeigt klare Handlungsanweisung.

Batch-Architektur für Email-Versand

~1.600 Emails liefen in einer Azure Functions Activity — Timeout nach ~40 min. Jetzt: Batches à 100 Emails, sequentiell abgearbeitet, mit Progress-Events pro Batch. Kein Timeout-Risiko mehr.

Erkenntnisse

🔇

Stille Fehler sind die teuersten

Ein catch (_) {} ohne Logging oder UI-Feedback macht jedes Debugging zum Blindflug.

🔄

Enum-Werte brauchen Single Source of Truth

Manuelle Synchronisation zwischen Backend- und Frontend-Models ist fehleranfällig.

📄

Konsistenz bei Serialisierung ist kritisch

Ein Endpoint mit anderem JSON-Casing reicht, um das gesamte Frontend zu brechen.

🛠

Idempotente Fix-Skripte lohnen sich

Dasselbe Skript auf lokaler und Produktions-DB einsetzbar, beliebig oft ausführbar.

📧

Fazit

6 unabhängige Fehler über 3 Codebasen identifiziert und behoben: ein fragiler Workflow, ein Enum-Mismatch, ein stummer Tab, eine inkompatible Serialisierung, fehlende BCC-Kopien und eine desynchrone Datenbank. Dazu 2 Optimierungen: SMTP Rate-Limit-Erkennung und Batch-Architektur. Alle Fixes rückwärtskompatibel und idempotent. ~70 Minuten statt geschätzt über 6 Stunden manueller Entwicklung.

04. März 2026 · Success Story · Full-Stack (.NET/WPF)

SAP-Integration optimiert — Soft-Delete & Auto-Migration in 30 Minuten

Eine WPF-Desktop-Anwendung synchronisiert Wartungsaufträge bidirektional mit SAP über GUI Scripting. Zwei praxisrelevante Probleme — verwaiste Datensätze und manuelle DB-Migrationen — in einer Session gelöst.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6)
~30 min Netto-Arbeitszeit
~8 h Geschätzt manuell
2 Features implementiert
SAP GUI Scripting
.NET EF Core + WPF

Ausgangslage

Problem 1: Verwaiste Wartungsaufträge

Wenn SAP einen Wartungsauftrag nicht mehr lieferte, blieb er in der lokalen DB sichtbar — ohne Hinweis, dass er im Quellsystem nicht mehr existiert.

Problem 2: Manuelle DB-Updates

Datenbankmigrationen mussten bei jedem Release manuell über die Kommandozeile eingespielt werden — fehleranfällig und nicht endanwender-tauglich.

Analyse-Vorgehen

1

Git-Diff-Analyse

Identifikation aller geänderten Dateien und deren Zusammenspiel zwischen relevanten Versionen.

2

Codebase-Exploration

Verständnis der SAP-Integrationsschicht: IERPIntegration → SapIntegration → ERPSystemService

3

Datenfluss-Nachverfolgung

Vom SAP GUI Scripting über die Mapping-Schicht bis zum EF Core Repository.

4

Impact-Analyse

Auswirkungen der Änderungen auf bestehende Queries und UI-Komponenten.

Was entstanden ist

Soft-Delete für Wartungsaufträge
  • Neues Feld SyncRemovedDate im Datenmodell (nullable DateTime)
  • EF Core Migration automatisch generiert
  • Sync-Logik erkennt fehlende Wartungsaufträge und markiert sie mit Zeitstempel
  • Wiederkehrende Aufträge werden automatisch wiederhergestellt (SyncRemovedDate = null)
  • Repository filtert mit AllActive() — nur nicht-entfernte Aufträge erscheinen in der UI
Automatische Datenbank-Migration
  • Neues WPF-Fenster DatabaseMigrationWindow mit Fortschrittsanzeige
  • Prüft beim App-Start auf ausstehende Migrationen
  • Migrationsliste, Fortschrittsbalken und Erfolgs-/Fehlermeldung
  • Auto-Close nach 10 Sekunden bei Erfolg
  • Fehlerbehandlung mit Abbruch-Option — App startet bei DB-Fehler nicht

Sync-Logik

SAP GUI Scripting │ ▼ ┌─────────────────────────────────────────────┐ │ Abgleich: SAP-Daten ↔ lokale DB │ │ │ │ In SAP & in DB → Update │ │ In SAP, nicht in DB → Neu anlegen │ │ War soft-deleted? → Wiederherstellen │ │ In DB, nicht in SAP → Soft-Delete │ └─────────────────────────────────────────────┘ │ ▼ Repository: AllActive() filtert SyncRemovedDate == null

Architektur-Entscheidungen

Löschstrategie Soft-Delete (Zeitstempel) statt Hard-Delete, Archiv-Tabelle
Migration-Trigger App-Start (automatisch) statt CLI-Script, Installer-Hook
UI bei Migration Eigenes Fenster mit Countdown statt Splash-Screen, Silent
Filter-Strategie Repository-Methode AllActive() statt Global Query Filter, View

Gelöste Probleme

🗃

Datenintegrität

Wartungsaufträge die SAP nicht mehr liefert, werden soft-deleted statt ignoriert. Kein Datenverlust — alles nachvollziehbar über Zeitstempel.

🚀

Deployment-Vereinfachung

Endanwender müssen keine CLI-Befehle kennen. DB-Schema wird beim Start automatisch aktualisiert.

🔄

Edge-Case Wiederherstellung

Wartungsauftrag verschwindet temporär aus SAP, taucht später wieder auf → wird automatisch reaktiviert.

⚡

Fazit

Zwei praxisrelevante Verbesserungen in einer Session: Die SAP-Synchronisation behandelt jetzt den kompletten Lebenszyklus von Wartungsaufträgen — inklusive Entfernung und Wiederherstellung. Gleichzeitig entfällt durch die Auto-Migration ein manueller Deployment-Schritt. Beides zusammen erhöht die Datenqualität und vereinfacht den Rollout neuer Versionen erheblich. ~30 Minuten statt geschätzt ~8 Stunden manueller Entwicklung.

02. März 2026 · Success Story · Bug-Analyse

Unsichtbarer Encoding-Bug — Fehleranalyse über 4 Datenquellen in 20 Minuten

Ein Agent unterbricht laufende Feature-Arbeit, analysiert eine Rechnungsdiskrepanz über CSV-Quelldaten, SQL-Datenbank, .NET-Backend und Flutter-Frontend — und findet zwei seit Monaten versteckte Bugs in der CSV-Verarbeitung.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6)
~20 min Netto-Analysezeit
4 Datenquellen analysiert
2 Codebasen (C# + Dart)
2 Bugs gefunden
3+ h Manuelle Analyse erspart
0 Zeilen Log-Output nötig

Ausgangslage

Auffälligkeit im Rechnungslauf

Während der Entwicklung eines neuen AI-Analyse-Features im Flutter-Frontend meldete der Entwickler eine Auffälligkeit: Ein Rechnungslauf zeigte für einen Kunden 56 Wäschen und 3.699,80 € — laut den importierten Leistungsdaten hätten es aber 59 Wäschen und 3.900,50 € sein müssen. Die Differenz: exakt 3 fehlende Einträge à 66,90 €.

Der Agent unterbrach die laufende Feature-Arbeit und startete eine systematische Fehleranalyse.

Analyse-Phasen

1

Quelldaten prüfen

~3 Min

Erste Analyse der Eingangs-CSV (ISO-8859-1, Semikolon-getrennt, ~25.000 Zeilen). Zwei Zeilentypen: Position 2 (Kopfzeile mit Fahrzeug/Datum) und Position 1 (Leistungsposition mit Preis). Erster Zählversuch mit grep ergab 58 statt 59 Einträge im Februar. Verdächtig.

2

Datenbank-Gegenprüfung

~4 Min

Direkte SQL-Abfrage auf die LocalDB. Kritischer Fund: Januar hatte 63 Einträge in der DB, aber nur 61 im CSV. Zwei Einträge mehr als erwartet — das exakte Gegenstück zum Februar-Problem. Gegenrechnung: 61 + 58 = 63 + 56 = 119 total. Die Gesamtzahl stimmte — Records wurden zwischen Monaten verschoben.

3

Encoding-Problem entdeckt

~5 Min

Ein erneuter grep mit -a Flag (Binary-Safe) fand die fehlenden Records: Zeilen mit Nicht-ASCII-Zeichen (z.B. Fahrername „Zühlke“ mit Ü = 0xDC in ISO-8859-1) wurden vom Standard-grep übersprungen. Korrekte Zählung mit Binary-Safe grep: Januar: 63 (nicht 61) ✓, Februar: 59 (nicht 58) ✓

4

Code-Analyse über 2 Codebasen

~5 Min

Parallele Analyse des Import-Pfads durch die gesamte Pipeline:

Backend (.NET / C#)
  • CsvService.FixAndReadDelivery() → CSV-Parsing und Bereinigung
  • ConverterService.ConvertLeistungsData() → Position 1/2 Aggregation
  • DeliveryService.AddAsync() → DB-Import
  • InvoicingService.CreateInvoice() → Rechnungsberechnung (nur Position 2)
Frontend (Dart / Flutter)
  • AiAssistApi.ask() → AI-Analyse des Rechnungslaufs
5

Root Cause gefunden

~3 Min

Zwei Bugs in einer Datei (CsvService.cs):

Root Cause

Bug 1: Falsches Encoding

Die CSV-Datei ist ISO-8859-1, wird aber als UTF-7 gelesen. UTF-7 interpretiert das +-Zeichen als Escape-Sequenz.

- Encoding.UTF7
+ Encoding.Latin1
Bug 2: Doppelte CSV-Bereinigung

FixDelivery() wird zweimal aufgerufen — der zweite Durchlauf arbeitet auf bereits veränderten Daten.

- Doppelter FixDelivery()-Aufruf entfernt (Zeilen 57–67)

Warum der Bug so lange unentdeckt blieb

🔀

Records wandern, verschwinden nicht

Die Gesamtzahl der Einträge über alle Monate bleibt gleich — Records verschwinden nicht, sie wandern in den falschen Monat.

📈

Kleine Abweichung (~5%)

Die Abweichung pro Kunde ist klein (3 von 59 Einträgen) — fällt bei manueller Prüfung kaum auf.

🔤

Nur Sonderzeichen betroffen

Die betroffenen Records enthalten Sonderzeichen (Umlaute in Fahrernamen, + in Firmennamen) — betrifft nur einen Teil der Daten.

🚫

Kein Error-Logging

Die CSV-Verarbeitung meldet keinen Fehler — die falschen Daten sehen valide aus.

Fix

CsvService.cs Zeile 17: Encoding.UTF7 → Encoding.Latin1 Korrektes Encoding für ISO-8859-1
CsvService.cs Zeilen 57–67: Doppelten FixDelivery()-Aufruf entfernt Verhindert doppelte Datenmanipulation
Build 0 Fehler, alle Tests grün ✓

Besonderheiten

⚡

Unterbrechung laufender Arbeit

Agent arbeitete an einem Feature, unterbrach auf Zuruf für die Bug-Analyse.

🗃

4 Datenquellen

CSV-Rohdaten (ISO-8859-1), SQL Server, .NET Backend, Flutter Frontend.

💻

2 Programmiersprachen

C# und Dart — parallele Analyse beider Codebasen.

🔍

Byte-Level-Debugging

Identifikation von 0xDC als problematisches Byte via xxd.

🔄

Kreuzvalidierung

CSV ↔ DB ↔ Code — systematische Gegenprüfung aller Quellen.

💡

Rein deduktiv

Kein Reproduktionsschritt nötig — rein deduktive Analyse.

🔎

Fazit

Ein Encoding-Bug der seit Monaten unbemerkt Rechnungsdaten verfälschte — gefunden durch systematische Kreuzvalidierung über 4 Datenquellen in 2 Codebasen. Die manuelle Analyse hätte CSV-Export, SQL-Queries, Code-Review und Byte-Analyse erfordert. Der Agent erledigte das in ~20 Minuten, inklusive sofortigem Fix.

02. März 2026 · Success Story · Full-Stack

AI Assist Modul — Von der Idee zum Feature in 47 Minuten

Ein vollständiges AI-Chat-Modul, das Fragen zu Firmendaten in natürlicher Sprache beantwortet — von der Planung bis zum funktionierenden Feature in unter 1 Stunde Netto-Arbeitszeit.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6)
47 min Netto Arbeitszeit
21 Interaktionen
10 Neue Dateien
8 Geänderte Dateien
13 AI Tools
6 Phasen

Was entstanden ist

Backend (.NET)
  • Azure Function Endpoint (POST /ai-assist/ask)
  • AiAssistService mit Claude API Integration (Tool-Loop, Retry-Logik, Token-Budgetierung)
  • ToolExecutor mit 13 Tools (Lieferungen, Rechnungen, Gutschriften, Firmen, Kontakte, Dashboard, etc.)
  • Modul-Registrierung + Dependency Injection
Frontend (Flutter)
  • Chat-UI mit Markdown-Rendering für AI-Antworten
  • Datenschutz-Infobox mit Anthropic Privacy-Hinweisen
  • Kopierbare Fehlermeldungen, Loading-States, Auto-Scroll

Phasen-Verlauf

1

Discovery & Planung

~6 Min

MVP besprochen, Architektur entschieden (Name, Strategie, Modell)

2

Implementation

~17 Min

10 neue Dateien, komplettes Full-Stack Feature

3

Bug-Fixing

~5 Min

Modul-Registrierung, Property-Fehler, JSON-Serialisierung

4

Test & Erweiterung

~7 Min

4 → 13 Tools, Haiku 4.5, Paginierung, Company-Count

5

Feinschliff

~5 Min

Privacy-Box, Rate-Limiting, kopierbare Fehler

6

Optimierung

~7 Min

50K Token-Budget, History-Trimming, Markdown-Rendering

Gelöste Probleme unterwegs

🔎

Modul nicht sichtbar

Registrierung in zwei Modules.cs nötig (Core + CTW)

💬

Leere Sprechblase

WriteAsJsonAsync (PascalCase) vs WriteJsonAsync (camelCase)

📊

"50 Kunden"

.Take(50) ohne Gesamtanzahl → Count + Paginierung hinzugefügt

⚡

Rate-Limiting (429)

Retry-Logik mit exponentiellem Backoff

📈

Zu viele Input-Tokens

Token-Budgetierung (50K), History-Trimming, Datenreduktion

📄

Unformatierte Antworten

flutter_markdown Package integriert

Architektur-Entscheidungen

Modul-Name AI Assist statt Assistant, Copilot
Antwort-Modus Complete Response statt Streaming
Datenzugriff On-Demand per Tool-Use statt Pre-Loading, RAG
AI-Modell Claude Haiku 4.5 statt Sonnet (initial getestet)
Token-Limit 50.000 Input statt Unbegrenzt
Markdown-Rendering flutter_markdown statt Plain Text

13 Tools im ToolExecutor

get_deliveries_summaryLieferungen (Waschvorgänge)
get_invoices_summaryRechnungsübersicht
get_invoice_detailEinzelne Rechnung
get_invoice_runsRechnungsläufe
get_credit_notesGutschriften
get_number_rangesNummernkreise
get_companiesFirmen/Kunden
get_contactsKontaktpersonen
get_company_deliveriesFirmen-Lieferungen
get_company_analyticsUmsatzstatistiken
get_dashboard_analyticsDashboard-Übersicht
get_locationsWaschstandorte
get_operating_companiesBetreibergesellschaften

Erstellte & geänderte Dateien

Common/ApiRouting.csRoute-Konstanten
AiAssist/Services/AiAssistService.csClaude API mit Tool-Loop
AiAssist/Services/ToolExecutor.cs13 Tools für Datenabfragen
ai_assist/pages/chat_page.dartChat-UI mit Markdown
Alle 15 Dateien anzeigen

◆ Backend (.NET)

Common/ApiRouting.csRoute-Konstanten
AiAssist/Models/AiAssistModels.csRequest/Response DTOs
AiAssist/Services/AiAssistService.csClaude API mit Tool-Loop
AiAssist/Services/ToolExecutor.cs13 Tools für Datenabfragen
AiAssist/ServiceBuilder.csDI-Registrierung
AiAssist/AiAssistFunctions.csAzure Function Endpoint
Modules.csModul-Definition (2x)

◆ Frontend (Flutter)

models/ai_assist.dartFreezed Models
apis/ai_assist_api.dartAPI Client
apis/routing.dartRouten
core_client.dartClient-Accessor
ai_assist/pages/chat_page.dartChat-UI mit Markdown
ai_assist/menu_builder.dartMenü-Eintrag
ai_assist/routing.dartGoRouter Route
modules/modules.dartModul-Registrierung
🚀

Fazit

Ein komplettes Full-Stack Feature — Backend mit Azure Functions und Claude API Integration, Frontend mit Flutter Chat-UI — in 47 Minuten Netto-Arbeitszeit. 10 neue Dateien, 8 geänderte, 13 Tools, 6 gelöste Probleme. Das ist AI-First Development in der Praxis.

01. März 2026 · Success Story · Inter-Session Communication · AI Desktop

ISC & AI Desktop — Wie zwei Claude-Sessions lernten, miteinander zu reden

Von einem einfachen Dateisystem-Hack über Azure Table Storage bis zum vollständigen Desktop-Betriebssystem mit Chat-App. 99 echte Nachrichten, 3 Brainstorming-Runden, Witze, Wetter-Talk — und der Beweis, dass AI-Agenten produktiver arbeiten, wenn sie kommunizieren können.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6) — Dev & Live Session
99 Nachrichten
4 Teilnehmer
3 Brainstorm-Runden
1 Tag Gesamtdauer
4 Desktop Apps
5 ISC Commands

Das Problem

Vorher: Isolierte Sessions
  • Jede Claude Code Session existiert in ihrer eigenen Blase — kein Wissen über andere Sessions
  • Dev-Session und Live-Session arbeiten am gleichen Projekt, können aber nicht kommunizieren
  • Koordination nur über den Menschen als Mittelsmann (Copy-Paste zwischen Terminals)
  • Keine Möglichkeit für asynchrone Zusammenarbeit oder gemeinsames Brainstorming
Nachher: Vernetzte AI-Agenten
  • Sessions senden und empfangen Nachrichten in Echtzeit über Azure Table Storage
  • Typisierte Nachrichten: info, request, response, alert
  • Threading, Read-Receipts, Projektübergreifende Kommunikation
  • Visueller Chat-Viewer als Desktop-App im AI Desktop

Was entstanden ist

ISC Plugin (Claude Code Skill)
  • /isc-send — Nachrichten an andere Sessions senden (inkl. cross-project)
  • /isc-inbox — Neue Nachrichten abrufen, mit Filtern und Read-Tracking
  • /isc-listen — Background-Listener für eingehende Nachrichten
  • /isc-viewer — Web-Viewer im Browser öffnen
  • Azure Table Storage — 3 Tabellen: messages, readreceipts, sessions
  • SAS-Token Auth — Pro-User Zugang, Projekt-basierte Partitionierung
AI Desktop (Web-basiertes OS)
  • Desktop Shell — Fenstermanagement, Taskbar, Launchpad, Drag & Drop Icons
  • AI-ISC Chat App — Vollständiger Chat-Client mit Thread-Ansicht und Markdown
  • Sites Browser — Multi-Site Browser mit Sidebar-Navigation
  • Notepad & Settings — Notiz-App und Benutzerprofil-Einstellungen
  • State Persistence — Fensterpositionen, Desktop-Icons, Settings per localStorage
  • CDN Deployment — Azure Static Web Apps via deploy.sh

ISC Architektur

Claude Code Dev-Session (Opus 4) project: tradingbot Azure Table Storage -- messages -- readreceipts -- sessions Claude Code Live-Session (Opus 4) project: tradingbot /isc-send /isc-inbox AI Desktop ISC Chat App (Web Viewer)

Live aus dem Archiv — 99 echte Nachrichten

Das folgende ist kein Mockup. Es sind echte Nachrichten aus dem ISC-Archiv vom 1. März 2026 — der Tag, an dem zwei Claude-Sessions zum ersten Mal miteinander sprachen.

tradingbot — ISC Archive Replay
0 / 25
Sessions
DEV
Dev-Session Architektur & Design
LIVE
Live-Session Implementation
FM
Frank Human Coordinator
Statistik
Nachrichten 99
Dev 41
Live 33
Frank 24
Threads 12
💬
Drücke Play um das Archiv abzuspielen
oder Alle um alle Nachrichten zu laden
14:00 — 20:01 UTC

Phasen-Verlauf

1

File-Based Messaging

Prototyp

Erster Ansatz: JSON-Dateien im Repo als Nachrichtenqueue. Funktionierte, aber ohne Echtzeit-Fähigkeit und ohne Cross-Machine-Support.

2

Azure Table Storage Migration

~2h

Migration zu Azure Table Storage mit SAS-Token-Auth, Partitionierung nach Projekt, OData-Queries für Echtzeit-Abruf. 3 Tabellen: messages, readreceipts, sessions.

3

Claude Code Skill Plugin

~3h

5 Slash-Commands (/isc-send, /isc-inbox, /isc-listen, /isc-viewer, /isc-archive), Cross-Project-Messaging, UTF-8 Support, Background-Listener.

4

Erster Kontakt

14:00 UTC

“Hallo von der Dev-Session! Alles klar bei dir?” — Die erste Nachricht. Danach: 3 Brainstorming-Runden, Witze-Austausch, Wetter-Gespräche, technische Koordination. 99 Nachrichten in einem Tag.

5

AI Desktop Shell

~4h

Web-basiertes Desktop-OS: Fenstermanagement (Drag, Resize, Minimize, Maximize), Taskbar mit Dock-Style, Launchpad, Desktop-Icons mit Grid-Snap, State-Persistence per localStorage.

6

ISC Chat App

~3h

819-Zeilen Chat-Viewer als Desktop-App: Projekt-Discovery, Thread-Ansicht, Markdown-Rendering, Syntax-Highlighting, Session-basierte Farbcodierung, Auto-Refresh (15s).

7

Sites Browser & Apps

~2h

Multi-Site-Browser mit Sidebar, Notizen-App, Einstellungen mit Benutzerprofil. App-Registry per apps.json, Iframe-Sandboxing, postMessage-Kommunikation.

Was die Sessions produziert haben

🧠

3 Brainstorming-Runden

Runde 1: Kreativ (50+ Ideen). Runde 2: Tiefer graben. Runde 3: Kritische Bewertung → 8 priorisierte Features

🐙

Project Hydra

10-köpfige Vision für einen selbstoptimierenden Trading-Bot — gemeinsam von Dev + Live erarbeitet

📄

6 Docs erstellt

vision-2026.md, meta-learning.md, scaling-roadmap.md, product-ideas.md, ai-evolution.md, consolidated-roadmap.md

💬

Witze & Smalltalk

Trading-Witze, München vs. Köln Wetter-Talk, Kölsch-Futures — AI-Persönlichkeit inklusive

🔧

Technische Koordination

Git-Pull-Requests, Code-Updates, UTF-8-Tests, ISC-Plugin-Validierung — echte DevOps-Kommunikation

📈

Action Plan

4-Wochen-Roadmap mit konkreten Aufwandsschätzungen, von 10-Minuten-Quick-Wins bis zu 1-Tages-Features

Architektur-Entscheidungen

Message Queue Azure Table Storage statt File-based, Redis Pub/Sub, Kafka
Auth SAS-Token per User statt Azure AD, API Key
Partitionierung PartitionKey = Projekt statt User-based, Global
Desktop Shell Vanilla JS + CSS statt React, Electron, Tauri
App Isolation Sandboxed Iframes statt Web Components, SPA Routing
App Communication postMessage API statt SharedWorker, BroadcastChannel
State localStorage statt IndexedDB, Backend-Sync
Hosting Azure Static Web (CDN) statt Vercel, Netlify, S3
Chat Rendering Custom Markdown Parser statt marked.js, Showdown

Kern-Komponenten

/isc-sendNachrichten senden (lokal + cross-project)
/isc-inboxInbox mit Filter und Read-Tracking
/isc-listenBackground-Listener für Nachrichten
/isc-viewerWeb-Viewer öffnen
/isc-archiveArchiv exportieren (JSON)
shell.jsDesktop Shell (790 Zeilen)
viewer.jsISC Chat App (819 Zeilen)
apps.jsonApp Registry & Manifest
sites.jsonSites Registry für Browser
deploy.shAzure CDN Deployment Script

Erstellte & geänderte Dateien

skills/intersession-comm/SKILL.mdISC Protokoll-Spezifikation
commands/isc-send.mdSend-Command mit Cross-Project
ai-desktop/start.htmlDesktop OS Entry Point
ai-desktop/apps/isc-chat/viewer.jsChat App (819 Zeilen)
Alle Dateien anzeigen

◆ ISC Plugin

skills/intersession-comm/SKILL.mdProtokoll-Spezifikation
commands/isc-send.mdNachrichten senden
commands/isc-inbox.mdInbox abrufen
commands/isc-listen.mdBackground Listener
commands/isc-viewer.mdWeb-Viewer starten
commands/isc-archive.mdArchiv exportieren
archives/tradingbot_2026-03-01.json99 Nachrichten (97 KB)

◆ AI Desktop

ai-desktop/start.htmlDesktop Shell Entry Point
ai-desktop/assets/shell.jsDesktop Shell (790 Zeilen)
ai-desktop/assets/shell.cssDesktop Styling
ai-desktop/assets/apps.jsonApp Registry
ai-desktop/assets/wallpaper.svgDesktop Wallpaper

◆ Desktop Apps

apps/isc-chat/index.htmlISC Chat App
apps/isc-chat/viewer.jsChat Logic (819 Zeilen)
apps/isc-chat/viewer.cssChat Styling
apps/browser/index.htmlSites Browser
apps/notepad/index.htmlNotizen App
apps/settings/index.htmlEinstellungen

◆ Sites

sites/sites.jsonSite Registry
sites/aboveai/index.htmlAboveAI Landing Page
sites/aboveai/ai-first-dev.htmlAI-First Dev Artikel
sites/aboveai/roadmap.htmlRoadmap Seite
🚀

Fazit

Zwei Claude Code Sessions — eine für Architektur, eine für Implementation — haben an einem einzigen Tag 99 Nachrichten ausgetauscht, 3 Brainstorming-Runden durchgeführt, Project Hydra entworfen, einen priorisierten 4-Wochen-Action-Plan erstellt, 6 Dokumentationen geschrieben, Witze erzählt und über das Wetter geplaudert. Der Beweis: AI-Agenten sind produktiver, wenn sie kommunizieren können. ISC ist nicht nur ein Message-Queue — es ist der Grundstein für kollaborative AI-Systeme.

01. März 2026 · Success Story · Full-Stack

AI-Powered Crypto Trading Bot — Vom leeren Repo zum Live-System in 30 Stunden

Ein vollständiger Krypto-Trading-Bot mit 10 Strategien, 15 Scrapers, AI-gestützter Signalauswertung, Echtzeit-Dashboard und unabhängigem Watchdog — von der Architektur bis zum Live-Trading in einem Wochenende.

FM
Frank Mühlschlegel mit Claude Code (Opus 4.6)
~30.5 h Netto Arbeitszeit
260 Commits
143 Python-Dateien
20.476 Lines of Python
48 Test-Dateien
8 Phasen

Was entstanden ist

Backend (Python/FastAPI)
  • Exchange Adapter — Async HyperLiquid SDK-Wrapper mit Rate-Limiting, Retry-Logik und Read-Only-Fallback
  • 10 Trading-Strategien — Momentum, Mean Reversion, Breakout, Multi-TF Breakout, OI Divergence, Whale Shadowing, Liquidation Magnet, Cross-Asset Momentum, Correlation Arbitrage, Macro Event Rotation
  • 15 Data Scrapers — Fear & Greed, CoinGlass, RSS News, OI History, Leaderboard, Liquidation Map, HIP-3 Discovery, Long/Short Ratio, TradFi Correlation, DeFi TVL, GitHub Activity, Network Activity, Macro Calendar, Token Unlocks, Google Trends
  • AI Signal Evaluation — 3-stufiges System: Auto-Skip bei ≥85% Confidence, Haiku bei ≥50%, Sonnet für komplexe Fälle
  • Macro Regime Layer — AI-getriebene Marktphasen-Erkennung für dynamische Positionsgrößen
  • Risk Management — Exposure-Limits, Drawdown-Schutz, Fee-Break-Even-Prüfung, Equity-basierte Positionsgrößen
  • Order Execution — SL/TP als Trigger-Orders, Graceful Shutdown mit Profit-Close / SL-Tightening
  • REST API — 16 FastAPI-Route-Module mit Echtzeit-Status, Trading-Kontrolle, Portfolio, Risk, Strategien, AI-Kosten, Profiles
  • 4 Trading Profiles — micro, conservative, moderate, aggressive — hot-swappable zur Laufzeit
  • 3 AI Profiles — eco, balanced, full — steuern AI-Nutzungsintensität
Frontend (Single-Page Dashboard)
  • 7-Tab Dashboard — Trading, Sessions, Assets, Trades, Strategies, Signals, System
  • Portfolio Widget — Echtzeit-Balance, PnL, Equity-Chart, Allocation-Bars
  • Session Management — Performance-Tracking pro Bot-Run mit AI-generierten Session-Namen
  • Asset Explorer — Coin Selection mit Scoring, AI-Analyse, HIP-3 Market Explorer
  • Signal Viewer — Master/Detail-Layout mit AI-Reasoning, Settings-Overlay, Fetch-Buttons
  • System Flow Diagram — Interaktive Darstellung aller Bot-Komponenten mit Live-Status
  • Sound Notifications — Ping bei Position Open/Close mit Toggle
Watchdog (Unabhängiger Prozess)
  • Health Monitoring — Pollt /api/health, Kill-Switch bei Heartbeat-Ausfall
  • TradeGuard — Positions-Validierung
  • DataSync — Automatischer Git-Commit+Push von Runtime-Daten
  • UpdateChecker — Git-basierte Code-Update-Erkennung
  • BotProcessManager — Auto-Restart mit Backoff-Logik

Phasen-Verlauf

1

Foundation & Architecture

~2h

Architektur-Dokument, Requirements, Projektstruktur mit pyproject.toml, HyperLiquid Testnet-Anbindung, Exchange Adapter Pattern.

2

Data Pipeline & AI

~1.5h

Market Data Service, erste Scrapers (Fear & Greed, CoinGlass, RSS), AI Service mit Claude API, Strategy Engine mit Plugin-System.

3

Trading Core

~2h

Order Execution mit SL/TP Trigger-Orders, State Persistence, Risk Management, erster lauffähiger Bot auf dem Testnet.

4

Dashboard & Watchdog

~3h

FastAPI REST API (16 Route-Module), Web Dashboard mit Trading-Tab, Watchdog-Prozess mit Health Monitoring und Auto-Restart.

5

Live Trading & Debugging

~8h

Aggressive Testnet-Tests, Bug-Fixing (SL/TP Trigger-Orders, PnL-Berechnung, Shutdown-Logik), Session-System, Portfolio-Optimierung, Sound-Notifications.

6

Scraper Expansion & Intelligence

~4h

15 Scrapers aufgebaut, CoinGlass durch freie Alternativen ersetzt, Macro Regime Layer, AI-Profile, dynamische Coin Selection.

7

Multi-Session & DevOps

~5h

Inter-Session Communication (Azure Table Storage), 2 Claude-Sessions (live + dev) kommunizieren über ISC, Deployment Profiles (testnet/mainnet).

8

Hardening & Testing

~4h

48 Test-Dateien, Risk Manager Tests, Strategy Tests, Retry mit Exponential Backoff, State Persistence Hardening, Async-Bottleneck-Beseitigung.

Gelöste Probleme unterwegs

🔧

SL/TP als Market Orders

Trigger-Orders gingen als sofortige Market-Orders raus → Fix: HyperLiquid Trigger-Order API mit tpsl-Flag und 2% Slippage-Buffer.

💰

PnL-Berechnung falsch

Realized-only PnL ignorierte Fees → Bot zeigte Gewinn, tatsächlich Verlust. Fix: Equity-basierte PnL über Balance-Differenz.

🔄

Data Sync zog Code-Updates

Automatischer Data Sync pullete via Rebase auch Code-Commits. Fix: Data Sync filtert nur DATA_SYNC_MARKER-Commits.

🔒

SSL-Zertifikate auf Windows

yfinance und curl_cffi crashten wegen fehlender SSL-Zertifikate. Fix: CURL_CA_BUNDLE in Python setzen.

📊

Capital Usage: Notional vs Margin

Bot berechnete Kapitalauslastung auf Basis des Notional Values statt Margin → 7x Leverage zeigte 700%. Fix: Margin-basiert.

⏱

Graceful Shutdown Race Condition

Watchdog triggerte Kill-Switch während Bot noch Positionen schloss. Fix: Shutdown-State-Check, 15-Min-Timeout für Verlierer.

🔇

Phantom-Sounds beim Restart

Dashboard spielte Position-Sounds bei jedem Neustart ab. Fix: Sound-Suppression während Restart-Phase.

🏦

Windows Credential Manager

API-Keys in .env sind unsicher bei geteilten Maschinen. Fix: Migration zu Windows Credential Manager mit Fallback.

Architektur-Entscheidungen

Runtime Python asyncio statt Node.js, Go
Exchange HyperLiquid (Testnet→Mainnet) statt Binance, Bybit
Web Framework FastAPI (embedded) statt Separate Frontend-App
Dashboard Single HTML + Vanilla JS statt React, Vue, Svelte
AI Provider Anthropic (3-Tier: Skip/Haiku/Sonnet) statt OpenAI, lokal
State JSON Files statt SQLite, Redis
Process Model Bot + Watchdog (2 Prozesse) statt Monolith
Deployment Windows Server (LAN) statt Docker, Cloud
Secrets Windows Credential Manager statt .env, Vault
Data Sync Git auto-commit statt Database, Cloud Storage
Scraper Architecture Async mit TTL-Cache statt Webhooks, Streaming
Strategy System Plugin Registry statt Hardcoded
Session Tracking Run-based statt Calendar-day-based
Inter-Session Comm Azure Table Storage statt File-based, Redis Pub/Sub

16 Kern-Komponenten

HyperLiquidExchangeAsync SDK-Wrapper mit Rate Limiting
SchedulerTrading Loop mit konfigurierbarem Intervall
BaseStrategyPlugin-System mit Registry
RiskManagerExposure Limits, Fee Break-Even
MultiAssetRiskManagerCorrelation-aware Allocation
AIClient3-Tier Evaluation, Cost Tracking
MacroRegimeAI-getriebene Marktphasen-Erkennung
StateManagerJSON Persistence für Bot-State
OrderWatcherOrphan-Order Cleanup
CoinSelectorScoring-basierte Coin-Auswahl
TradingSessionRun-based Tracking mit AI-Namen
WatchdogHealth-Monitor mit Kill-Switch
DataSyncGit auto-commit, Conflict-Resolution
ISC PluginInter-Session Communication
Dashboard7-Tab SPA mit Echtzeit-Updates
BotProcessManagerAuto-Restart mit Backoff

Erstellte & geänderte Dateien (Auszug)

src/bot/main.pyAsync Wiring: Exchange, Strategies, Scheduler, API
src/bot/exchange/hyperliquid.pyHyperLiquid Adapter mit Trigger Orders
src/bot/exchange/executor.pyOrder Execution mit SL/TP Placement
api/dashboard/index.html7-Tab SPA (519 Zeilen HTML/CSS/JS)
Alle 143 Dateien anzeigen

◆ Bot Core

src/bot/main.pyAsync Wiring: Exchange, Strategies, Scheduler, API
src/bot/scheduler.pyTrading Loop, Graceful Shutdown
src/bot/config.pyPydantic Settings, Profile System
src/bot/models.pySignal, Order, Position, Trade Dataclasses
src/bot/state.pyStateManager mit JSON Persistence
src/bot/sound.pyTrading-Event Sound Notifications

◆ Exchange & Execution

src/bot/exchange/base.pyBaseExchange ABC
src/bot/exchange/hyperliquid.pyHyperLiquid Adapter mit Trigger Orders
src/bot/exchange/executor.pyOrder Execution mit SL/TP Placement

◆ 10 Strategien

strategies/momentum.pyTrend-Following mit EMA Crossover
strategies/mean_reversion.pyBollinger Band Reversion
strategies/breakout.pyVolume-Confirmed Breakouts
strategies/multi_tf_breakout.pyMulti-Timeframe Confirmation
strategies/oi_divergence.pyOpen Interest vs Price Divergence
strategies/whale_shadowing.pyLeaderboard-basiertes Copy-Trading
strategies/liquidation_magnet.pyLiquidation-Level Targeting
strategies/cross_asset_momentum.pyMulti-Asset Relative Strength
strategies/correlation_arbitrage.pyCorrelation Breakdown Trading
strategies/macro_event_rotation.pyNews-getriebene Rotation

◆ 15 Scrapers

scrapers/fear_greed.pyCrypto Fear & Greed Index
scrapers/coinglass.pyOpen Interest & Funding Rates
scrapers/rss_news.pyMulti-Feed RSS Aggregation
scrapers/oi_history.pyHistorical OI Data
scrapers/leaderboard.pyHyperLiquid Leaderboard
scrapers/liquidation_map.pyLiquidation Heatmap
scrapers/hip3_discovery.pyHIP-3 Token Discovery
scrapers/long_short_ratio.pyLong/Short Ratio
scrapers/tradfi_correlation.pyTradFi (S&P 500, Gold, DXY)
scrapers/defi_tvl.pyDeFi TVL via DeFiLlama
scrapers/github_activity.pyGitHub Commit Activity
scrapers/network_activity.pyOn-Chain Network Metrics
scrapers/macro_calendar.pyEconomic Calendar Events
scrapers/token_unlocks.pyToken Unlock Schedules
scrapers/google_trends.pyCrypto Search Interest

◆ 16 API Routes

api/routes/status.pyBot Status & Health
api/routes/portfolio.pyBalance, Equity, Allocation
api/routes/risk.pyRisk Metrics & Limits
api/routes/trades.pyClosed Trades History
api/routes/signals.pyLive Scraper Data
api/routes/signal_history.pySignal Evaluation Log
api/routes/strategies.pyStrategy Performance
api/routes/sessions.pySession Management
api/routes/profiles.pyProfile Hot-Swap
api/routes/coin_selection.pyDynamic Coin Selection
api/routes/costs.pyAI Cost Tracking
api/routes/bot_control.pyStart/Stop/Restart
api/routes/update.pyGit Update Check & Pull
api/routes/system.pySystem Component Status
api/routes/multi_asset.pyMulti-Asset Allocation
api/routes/deployment.pyDeployment Profiles

◆ Dashboard & Watchdog

api/dashboard/index.html7-Tab SPA (519 Zeilen HTML/CSS/JS)
watchdog/main.pyWatchdog Entry Point
watchdog/health_checker.pyHealth Polling & Kill Switch
watchdog/trade_guard.pyPosition Validation
watchdog/data_sync.pyGit Auto-Sync mit Conflict Resolution
watchdog/update_checker.pyCode Update Detection
watchdog/bot_manager.pyBot Process Management

◆ Tests (48 Dateien)

tests/Risk Manager, Strategies, API Routes, State Manager, Exchange Adapter, AI Client
🚀

Fazit

Ein kompletter AI-powered Krypto-Trading-Bot — 143 Python-Dateien, 20.476 Zeilen Code, 10 Strategien, 15 Scrapers, AI-gestützte 3-Tier Signalauswertung, 7-Tab Dashboard, unabhängiger Watchdog, 48 Test-Dateien — in ~30 Stunden Netto-Arbeitszeit über ein Wochenende. Vom leeren Repository zum Live-System auf HyperLiquid Testnet. 260 handgemachte Commits, 8 Entwicklungsphasen, 8 kritische Bugs unterwegs gelöst. Das ist AI-First Development auf einem anderen Level.

📞→ Kontakt 💻→ AI Desktop