Schnell-Index — Projekt anklicken
Trading & Finanzen
🟢InvestPiAutonomes Aktien-Trading (Paper über Alpaca). Bewertet jede Aktie laufend mit 20 Kennzah…🟢DayPiAutonomer Intraday-Day-Trader, Schwester-System zu InvestPi — aber Intraday statt Swing.…🟢PokéPiPokéPi ist ein vollautomatischer Pokémon-Karten-Schnäppchenjäger. Er scannt rund um die …Social & Content
🟢InstaPiVollautomatische Social-Media-Maschine fuer zwei KI-Charaktere (Mila und Riley). Das Sys…⏸️AutoPiAutoPi ist Merts persoenliches Gebrauchtwagen-Assistent-System. Es sucht automatisch auf…Publishing
🟢BookPiVollautomatische eBook-Fabrik fuer Amazon KDP. Das System waehlt selbst eine Nische, sch…Creator-Tooling
🟢BeatFactoryBeatFactory ist eine vollautomatische KI-Musik-Fabrik auf dem Raspberry Pi: Sie erfindet…Infrastruktur
🟢Pi-BasisDie gemeinsame Grundinfrastruktur des Pi — gehört keinem einzelnen Projekt, hält aber al…Trading & Finanzen3
InvestPi🟢 läuftAutonomes Aktien-Trading (Paper über Alpaca). Bewertet jede Aktie laufend mit 20 Kennzahlen, handelt nach Regeln + Sicherheitsbremsen, misst das Ergebnis und lernt daraus — ein geschlossener Kreislauf.
Autonomes Aktien-Trading (Paper über Alpaca). Bewertet jede Aktie laufend mit 20 Kennzahlen, handelt nach Regeln + Sicherheitsbremsen, misst das Ergebnis und lernt daraus — ein geschlossener Kreislauf.
Funktionsweise
- Quellen — yfinance · FRED · Google-Trends · Short-Interest
- heuristic-v5 — 20 Dimensionen → Risiko-Score 0–100 (live gewichtet)
- Decision Engine — Score + HMM-Regime → Kaufen/Halten/Verkaufen + Positionsgröße
- Risk-Limits — Stop-Loss · Cash-Floor · Sektor-Cap · Korrelation · Daily-Loss · Kill-Switch
- Alpaca (Paper) — Order-Ausführung, hält die Positionen
- Outcome-Messung — nach 7 Tagen: war der Score richtig?
- Attribution — welche der 20 Dimensionen haben getroffen?
- Weight-Optimizer — Gewichte aus 60-Tage-Attribution anpassen ↺ zurück zu heuristic-v5
Automatisierungen
Trading
strategy-hourlyMo–Fr stündl. 10–21
Autonomes Handeln: Buy/Sell/Stops.
rebalanceMo–Fr 21:30
Sell-only Pass (Stop/TP) zum Close.
rotationSa 12:00
Portfolio-Rotation: schwach raus, stark rein.
monthly-dca1. d. Monats 14:00
Monatlicher Sparplan-Pick.
dca-watchdogtäglich 18:00
Überwacht DCA-Positionen auf Probleme.
Lernen
scorestündlich :30
Risk-Scoring aller Titel + Universe-Scan.
outcomestäglich 02:30
Outcome-Messung + Drift-Erkennung.
train-regimeSa 05:00
HMM-Regime-Modell neu trainieren.
patterns1. d. Monats 03:00
Drawdown-Muster-Bibliothek aktualisieren.
meta-review2. d. Monats 04:00
Opus-Tiefenanalyse + Config/Code-Patches.
universe-screener1. d. Monats 06:00
Neue Kandidaten screenen.
Reports
daily-reporttäglich 21:30
Tages-Performance via Telegram.
weekly-mini-reviewSo 10:00
Sonnet-Wochenanalyse.
weekly-recapSo 19:00
Wochen-Recap (Hit-Rate, Best/Worst).
monthly-digest3. d. Monats 09:00
Monatlicher Verbesserungs-Digest.
Daten
syncstündlich :35
Broker → DB Sync + Equity-Snapshot.
status-pushalle 2 Min
Status/Equity nach Telegram & GitHub.
auto-pullalle 2 Min
Git-Pull = Auto-Deploy in <2 Min.
Infrastruktur
operatortäglich 13:00
System-Health-Check + Auto-Fixes vor Open.
hardwarealle 30 Min
CPU/Disk/RAM-Check mit Alert.
backuptäglich 03:30
DB-Backup (lokal + optional restic).
telegram-callbacksalle 60s
Verarbeitet Telegram-Eingaben.
Daten & Datenbank
trading.db
Das Paper-Konto & die Ausführung.
positionstradesequity_snapshots
learning.db
Herz des Self-Learning — jede Vorhersage + Auswertung.
predictionsreflectionsweight_snapshotsregime_snapshotsmeta_reviewsconfig_patch_logstrategic_recommendationscost_ledgerfeedback_reasonskv_store
market.db
Kurs- & Fundamentaldaten-Cache (yfinance).
pricesfundamentals
alerts.db
Risiko-Scores & versendete Benachrichtigungen.
risk_scoresnotifications
patterns.db
Historische Drawdown-Muster (ML-Input).
drawdown_eventspre_drawdown_features
Daten & Quellen
yfinance
Kurse, Volumen & Fundamentaldaten
FRED
Makro-/Zinsdaten (Wirtschaftslage)
Google Trends
Aufmerksamkeits-Signale
Short-Interest
Leerverkaufs-Quote
Alpaca (Paper)
Broker — führt Trades aus, hält Positionen
19 Risiko-Dimensionen
intern aus Kursen berechnet
Wer/was arbeitet
heuristic-v5
Regel-Engine: 19 Kennzahlen, gratis, im Sekundentakt
Opus 4.8
strategische Reviews, Pattern-Mining, Meta-Analyse
Claude-Operator
setzt tiefere Verbesserungen mit Mert um
Technik
SprachePython 3.11 (nativ, kein Docker)
Datenhaltung5× SQLite — trading, learning, market, alerts, patterns
Scheduling17 systemd-Timer · User investpi
Marktdatenyfinance · fredapi (FRED)
ML / Regimehmmlearn (HMM) · scikit-learn · Hurst/VaR eigen
BrokerAlpaca SDK (Paper-Account)
AlertsTelegram Bot API
Risiko-Engineheuristic-v5 · 20 gewichtete Dimensionen
KI-ReviewsClaude Opus 4.8 (wöchentlich/monatlich)
Deploygit auto-pull alle 2 Min → push = Live in <2 Min
Notizen
EUR-denominiert, Paper-Trading. Ziel: maximale absolute Rendite — aber mit Risikoabwägung, nicht gepokert. Die 20 Dimensions-Gewichte werden vom Lern-Loop aus 60-Tage-Attribution laufend auto-optimiert (heute zuletzt nachjustiert).
DayPi🟢 läuftAutonomer Intraday-Day-Trader, Schwester-System zu InvestPi — aber Intraday statt Swing. Handelt US-Aktien per Opening-Range-Breakout auf 'Stocks in Play' (echte Tages-Mover), eigenes Alpaca-Paper-Konto, KEIN Overnight-Risiko (alles vor Close glattgestellt). Trainiert im Walk-Forward-Backtest auf SIP-Historie, forward-testet live-paper.
Autonomer Intraday-Day-Trader, Schwester-System zu InvestPi — aber Intraday statt Swing. Handelt US-Aktien per Opening-Range-Breakout auf 'Stocks in Play' (echte Tages-Mover), eigenes Alpaca-Paper-Konto, KEIN Overnight-Risiko (alles vor Close glattgestellt). Trainiert im Walk-Forward-Backtest auf SIP-Historie, forward-testet live-paper.
Funktionsweise
- Screener — dynamisches Universum (feste Basis + taegl. Alpaca most-actives) → Stocks-in-Play per OR-Volumen-Spike
- Opening Range — erste 5 Min (15:30–15:35 CEST) → OR-High/-Low + ATR je Mover
- Stocks-in-Play-Filter — nur Titel mit OR-Volumen ≥ 2,2× Median (= die Edge-Quelle)
- Breakout — Kurs über OR-High → Long, unter OR-Low → Short (Entry nur bis 17:30 CEST)
- Bracket-Order — Alpaca: Entry + ATR-Stop (×0,5) + Take-Profit (1,5R), Sizing 1% Risk
- Flat-before-Close — 10 Min vor Schluss alles glattstellen — kein Overnight-Risiko
- Equity/Trade-Log — daypi.db → Snapshot → Webapp (DayPi-Tab)
Automatisierungen
daypi-live.timerminuetlich · Boersenzeit
Der Taktgeber: ruft jede Minute waehrend der US-Boersenzeit (Mo-Fr) den Handels-Tick auf. Ausserhalb der Boersenzeit passiert nichts. Steht dieser Timer, handelt daypi gar nicht.
Live-Tick (daypi_live.py)pro Tick
Das Gehirn pro Minute: setzt morgens die Ausbruchs-Marken der aktivsten Tages-Aktien, kauft (oder verkauft leer), sobald ein Titel sauber ausbricht — immer mit automatischem Stop und Gewinnziel — und stellt kurz vor Boersenschluss alles glatt (kein Uebernacht-Risiko).
Public-Snapshotje Tick
Schreibt nach jedem Tick eine kleine Status-Datei (offene Positionen, Trades, Gewinn/Verlust), die der DayPi-Tab in der InvestPi-Webapp anzeigt — so siehst du den Live-Stand im Browser.
daypi-snapshot.servicealle 2s · Boersenzeit
Haelt die Live-Anzeige fluessig: aktualisiert die Status-Datei waehrend der Boersenzeit alle paar Sekunden mit aktuellen Kursen/Positionen, damit die Webapp nicht einfriert.
Walk-Forward-Optimizerauf Abruf
Das Lern-Werkzeug (auf Abruf): spielt die Strategie auf historischen Minutendaten durch, sucht die besten Parameter und prueft sie an ungesehenen Daten gegen — nur was sich dort bewaehrt, geht live. Schuetzt vor Ueberanpassung an die Vergangenheit.
Daten & Datenbank
daypi.db
Trades, Signale, OR-Levels, Intraday-Equity, Predictions.
tradessignalsorb_levelsequity_intradaypredictions
Strategie — Opening-Range-Breakout
1 · Mover wählenrel-Vol-Spike
Aus der liquiden Universe die Titel mit echtem OR-Volumen-Spike (≥ 2,2× eigener 20-Tage-Norm).
2 · Opening Range5 Min
Hoch/Tief der ersten 5 Min nach US-Open als Ausbruchs-Level.
3 · Filter (Edge!)rel-Vol ≥ 2,2×
Nur Titel mit OR-Volumen ≥ 2,2× 20-Tage-Median handeln.
4 · EntryTop-3/Tag
Long über OR-High / Short unter OR-Low — nur morgens (Cutoff 17:30).
5 · Exit1,5R / Flat
ATR-Stop (×0,5) ODER Take-Profit (1,5R) ODER Flat vor Close.
Daten & Quellen
Alpaca IEX
Echtzeit-Minutenbars (gratis, ~letzte 15 Min)
Alpaca SIP
10 J. historische Minutendaten gratis (Training)
Dynamisches Universum (~140)
feste Basis-Liste + taegl. Alpaca most-actives (liquide), auf OR-Volumen-Spike gefiltert
Alpaca Paper
eigenes Konto PA376S45JBZR ($100k, 4× BP)
Wer/was arbeitet
ORB-Engine
Regel-basiert (keine KI im Minuten-Loop = günstig + schnell)
Walk-Forward-Optimizer
Grid-Search + OOS-Validierung
Meta-Review (geplant)
Opus periodisch — Strategie-/Param-Anpassung
Technik
SprachePython 3.13 (nativ, kein Docker)
Broker/Datenalpaca-py 0.43.4 (Paper + Market Data)
Analysepandas 3.0 · numpy 2.4 · eigener Backtester
StorageSQLite (WAL) — daypi.db
Schedulingsystemd-Timer (minütlich Marktzeit), TimeoutStartSec=90
Pfad/home/pi/daytrader · User pi
Roadmap — 6 Phasen
✅ Phase 0 — Fundament
Projektgerüst + Secretsfertig
/home/pi/daytrader, .alpaca.env (600), config.yaml
DB-Schemafertig
trades, signals, orb_levels, equity_intraday, predictions
Broker-Adapterfertig
alpaca_client.py gegen neues Paper-Konto verifiziert
Daten-Layerfertig
Alpaca Minutenbars (IEX live + SIP Historie)
✅ Phase 1 — Daten & Simulator
Daten-Cachefertig
data_cache.py — Pickle, 60 Symbole × 150 T (~256 MB)
Backtest-Enginefertig
backtest.py — Filter-Vergleich, realistische Slippage (3 bps)
Walk-Forwardfertig
70/30 Train/Test-Split, Out-of-Sample-Validierung
✅ Phase 2 — Strategie v1 + Intraday-Risk
ORB · Stocks-in-Playoptimiert
OR 5 Min, rel-Vol ≥ 2,2×, Top-3 (Filter = die Edge)
ATR-Stop + 1,5R-Targetoptimiert
ATR×0,5-Stop, Take-Profit bei 1,5R (OOS-validiert)
Risk-Bremsenaktiv
Risk/Trade, Daily-Loss-Stopp, Max-Trades/Tag, Brutto-Hebel-Cap — aktuelle Werte live in der Parameter-Ansicht
Flatten-before-Closeaktiv
gehärtetes close_all (Retry + Einzel-Fallback)
🔄 Phase 3 — Self-Learning-Loop
Walk-Forward-Optimizerfertig
optimize.py — Grid-Search, OOS Sharpe 1,15 (robust)
Predictions → Outcomesfertig
settle.py rechnet geschlossene Trades real ab → trades.pnl + predictions-Outcome (P/L, %, R)
Attribution + Backtest-Gateoffen
welche Signale/Params wirken — gegen Overfit
✅ Phase 4 — Live-Paper Forward-Test
Echtzeit-Looplive
daypi-live.timer minütlich Marktzeit (deployed)
Webapp-Integrationlive
Snapshot-Brücke → DayPi-Tab in der InvestPi-Webapp
Erste echte Sessionheute
heute 15:30 CEST (US-Open) — Sim-zu-Live-Test
Meta-Review (Opus)offen
periodische Strategie-Anpassung
⬜ Phase 5 — Skalierung
Strategie-Portfoliogeplant
mehrere Edges (VWAP-Momentum, Pairs) + Regime-Awareness
Daten-Upgradebei Bedarf
SIP-Live (Polygon/Alpaca) — erst wenn Ergebnisse es rechtfertigen
Canvas-Integrationfertig
DayPi als 9. Projekt im Dashboard
Entscheidungs-Log
Liquiditaets-Filter live ergaenzt — duenne Blowup-Aktien (RGNX-Typ) raus, Edge bleibt2026-06-22
2026-06-22: Erste Session mit dem groesseren Universum endete -3% (Daily-Loss-Bremse sauber ausgeloest, Verlust gedeckelt). 2/3 des Verlusts kamen aus EINEM Trade: RGNX (duenne Biotech) mit +361 bps Entry-Slippage -> der schlechte Fill verdoppelte den Verlust (-1,98R statt ~-1R). Diagnose dank der neuen Slippage-Erfassung. liquidity_test.py (2 Jahre, Sweep ueber Ø taegl. $-Volumen): einen strengeren Liquiditaets-Filter zu setzen kostet ~KEINEN Edge (OR-R + Rendite ueber alle Schwellen ~flach/noisy, Trades fast unveraendert 1466->1448) -> Ausschluss duenner Namen = Gratis-Versicherung gegen genau solche Fills. UMGESETZT: config screening.min_dollar_vol_m=10 (Ø taegl. $-Volumen >= $10M; ACHTUNG IEX-Feed-Skala, nicht Gesamtmarkt). daypi_live.py filtert Kandidaten darunter raus (berechnet aus den ohnehin geladenen Minutenbars -> kein Extra-Call). Live verifiziert: 108 behalten / 28 raus; RGNX(0,6M)/CRMT(0,1M)/DFTX(3,9M)/KEEL(8,7M) + Junk (ADTX/AMC/ICCM...) raus, RBLX/BITO/VOO/SPY/NVDA bleiben. Greift ab naechster Session. ZUSATZ: session_check.py meldet jetzt den SCHLIMMSTEN Einzel-Fill + Alarm — der bloße Durchschnitt hatte RGNX faelschlich als unauffaellig (-4,9 bps!) kaschiert. Schwelle ggf. mit mehr Live-Daten justieren.
LIVE UMGESTELLT: Bot fischt jetzt im groesseren liquiden Teich (dynamisches Universum)2026-06-18
2026-06-18: Nach Validierung (Karte direkt darunter) den Live-Bot von der festen 61er-Liste auf ein taeglich dynamisches, groesseres Universum umgestellt. config.yaml: screening.dynamic=true, dynamic_top=100, min_price=$3, neue core_etfs-Liste. daypi_live.py baut die Tages-Watchlist jetzt aus screen_universe + core_etfs (IMMER als Basis) + Alpacas most_actives-by-trades (echte Tages-Mover, liquide; LIVE bias-frei, da Echtzeit-Auswahl). Penny-Filter (OR-High < min_price -> raus). DREI Sicherheitsnetze: (1) feste Basis-Liste bleibt -> most_actives-Ausfall = Bot handelt normal weiter; (2) Penny-Floor; (3) ALLE Risiko-Caps unveraendert (Daily-Loss 3%, max 10 Trades, max 4 Pos, Brutto 2x, 1% Risk/Trade). universe_test.py liest jetzt dieselbe config -> getestet == gehandelt. Live verifiziert: 139 Symbole statt 61, minute_bars-Abruf 47s (nur 1x taeglich beim Watchlist-Bau; systemd-Singleton verhindert Ueberlapp). GREIFT AB NAECHSTER SESSION (heutige Watchlist stand schon, lief noch mit alter Liste; laufende Trades unberuehrt). Reale Slippage der neuen, teils volatileren Namen wird durch die frische Slippage-Erfassung ueberwacht.
Groesseres LIQUIDES Universum schlaegt feste 61er-Liste klar (2-Jahres-Test) — Hebel #1+#22026-06-18
2026-06-18: scripts/universe_test.py gebaut und 2 Jahre (730 Tage / 501 Handelstage, 2024-06..2026-06) getestet: ALT (feste 61er screen_universe) vs NEU (61 + liquide Index/Hebel-ETFs + Alpacas most_actives BY TRADES = liquide, Preis-Floor $3 = 130 Symbole), gleiche Strategie/ Params/Kosten wie Live. ERGEBNIS #1 (groesserer Teich): NEU klar besser — OR/Trade +0,084R vs +0,045R (fast doppelt), OOS +0,142R vs +0,100R, Sharpe 2,15 vs 1,11, mehr Trades (1473 vs 1277). ERGEBNIS #2 (Mehrjahres-Halt): Edge in JEDEM Kalenderjahr positiv (2024 +0,053R, 2025 +0,071R, 2026 +0,147R) -> nicht an eine einzelne Marktphase gebunden. CAVEAT (ehrlich): NEU nutzt HEUTIGE most_actives -> Hindsight-Bias; die absoluten Renditen (NEU +217% / ALT +65% ueber 2J) sind OPTIMISTISCH, vertrauenswuerdig ist die RICHTUNG + relative Verbesserung + Jahres-Positivitaet, NICHT die exakte %. maxDD ~24% (NEU) vs 21% (ALT). WICHTIG: LIVE hat most_actives KEINEN Bias (waehlt in Echtzeit die an dem Morgen tatsaechlich aktivsten Namen) -> die Live-Mechanik ist sauberer als der Backtest. OFFEN: Live von fester 61er-Liste auf dynamisches taegliches most_actives-Universum (liquide + Preis-Floor) umstellen wuerde den bestaetigten Edge direkt verstaerken — noch nicht verdrahtet, wartet auf Merts Go. universe_test.py bleibt als Re-Check.
Entry-Slippage-Erfassung ergaenzt — Live-vs-Backtest jetzt messbar (SIP->IEX-Luecke)2026-06-18
2026-06-18: settle.py erfasst jetzt die ENTRY-SLIPPAGE je Trade = geplanter Einstieg (Mid-Quote bei Entscheidung, trades.price/predictions.entry) vs. realer Market-Fill (erster Alpaca-Fill). Vorzeichen so, dass >0 IMMER Kosten heisst (Long teurer / Short tiefer gefuellt). Gespeichert in predictions.outcome_json (entry_fill, entry_slip_ps/_bps/_r) — kein Schema-Umbau, kein neuer API-Call (Daten lagen schon in realized_by_symbol, nur der erste Fill wurde verworfen). WARUM: das ist das eine Stueck, das ueber Live-vs-Backtest entscheidet — der Backtest (inkl. 2,2-Schwelle) lief auf SIP, live wird auf IEX gehandelt; ohne Slippage-Messung weiss man bei einem Live-Knick nicht, ob er an der Feedluecke/Spread liegt oder am Edge. settle druckt pro Trade slip in bps/R + ein Tages-Aggregat (O Entry-Slippage). Logik an realen 17.06.-Fills verifiziert (Entry/Exit sauber per Zeitstempel getrennt). Greift automatisch ab dem 1. sauberen Live-Trade.
ORB-Edge robustheitsgeprueft — rel-Vol >= 2,2x / Top-3 sitzt auf Plateau, KEIN Overfit2026-06-18
2026-06-18: Nachdem das 2. Standbein verworfen war, den BESTEHENDEN ORB-Edge auf Overfit stressgetestet statt blind zu tunen (scripts/robustness.py). Faehrt die echten Live-Params (OR=5min, ATR-Stop x0,5, R=1,5) und variiert NUR den Selektions-Filter; Train 70% / OOS 30% ueber 84 Handelstage (Feb–Jun 2026). FRAGE: sitzt die Live-Schwelle rel-Vol >= 2,2x auf einem stabilen Plateau (robust, uebersteht SIP->IEX-Feedwechsel) oder ist sie ein fragiler Peak (ueberangepasst)? ERGEBNIS = ROBUST: OOS-OR ist ueber die GESAMTE Schwellen-Spanne 1,0–3,5 durchgehend positiv (+0,12 bis +0,19R, Sharpe 3–5) — der Edge haengt NICHT am exakten Wert. 2,2 ist sogar leicht konservativer als das OOS-Optimum (~2,0: +0,188R) und liefert die hoechste Full-Period-Rendite (+16,5%). Top-N-Sweep ebenfalls flach: Live Top-3 (+16,5%) solide, Top-4 OOS minimal staerker (Sharpe 5,17, +19,1%) aber im Rauschen. CAVEAT: nur 84 Tage, OOS=26 (duenn), absolute Sharpes nicht ueberinterpretieren — entscheidend ist die relative Stabilitaet, und die ist eindeutig. ENTSCHEIDUNG: ORB unveraendert lassen (rel-Vol >= 2,2x / Top-3), Edge ist live-tauglich und nicht overfit. robustness.py bleibt als Re-Check-Werkzeug.
Mean-Reversion als 2. Standbein VERWORFEN — unkorreliert, aber kein Edge nach Kosten2026-06-18
2026-06-18: Kontrarische Intraday-Mean-Reversion gebaut (src/strategy/meanrev.py, scripts/backtest_meanrev.py) und in 3 Stufen gegen ORB getestet (gleiche Daten/Universum/Kosten). FRAGE 1 Diversifikation = JA: Korrelation der Tages-R zu ORB ~0 (naiv +0,03, gefiltert -0,02 ueber 79 Tage) -> waere ein idealer Glaetter. FRAGE 2 Netto-Edge = NEIN (entscheidend): naiv 5039 Trades O -0,39R; mit Regime-Filter (Efficiency-Ratio <=0,35, nur Range-Tage faden, max 5/Tag, TP am Mittel) sogar O -1,38R (Win 16%). Diagnose: bei z-Score-Mean-Reversion auf 30-Min-Fenster ist die eingefangene Bewegung KLEINER als die Round-Trip-Kosten -> der Spread frisst den Edge. Param-Sweep (6 Kombinationen lookback/min-Sigma/Effizienz/Bracket): nur EINE knapp positiv bei optimistischen 3bps (+0,27R), und die kippt bei realistischen 6bps auf -0,05R; MR ist liquiditaetsspendend -> real eher 6bps+. ERGEBNIS: kein robuster, kostenfester Edge auf liquiden US-Large-Caps intraday — deckt sich exakt mit dem Research-Caveat. ENTSCHEIDUNG: Intraday-Mean-Reversion als 2. Standbein verworfen (weiteres Tunen = Overfit auf Optimistik-Kosten). Code/Config bleiben als dokumentiertes Tooling (config meanrev:, NICHT live verdrahtet). Wert des Tests: Verliereridee fuer ~0$ entlarvt, bevor Echtgeld im Spiel war. Naechste Richtung offen (anderer Edge ODER ORB haerten).
Research: zweites Standbein = Intraday Mean-Reversion (kontrarisch)2026-06-18
2026-06-18: Deep-Research-Session (20 Quellen, 25 Aussagen adversarial geprueft, 8 widerlegt) zur Frage, welche zweite, zu ORB moeglichst unkorrelierte Strategie sich als zweites Standbein eignet. Ergebnis: eine kontrarische Intraday-Mean-Reversion (kauft Schwaeche, verkauft Staerke) ist der mechanische Gegenpol zu ORB und soll an Range-/Seitwaerts-Tagen liefern, an denen ORB schwaechelt. Abgelehnt: VWAP-Strategie (selbst trendfolgend -> korreliert mit ORB), klassisches EOD-StatArb/Pairs (Edge verblasst, falsche Frequenz). Konkrete Startregel: z-Score auf Spread, Entry z=2, Exit z=1, ~100-Bar-Lookback (minuten-bar-backtestbar, Bracket-tauglich). WICHTIG/ehrlich: Wert ist Diversifikation/Equity-Glaettung, NICHT hohe Eigenrendite; Netto-Edge in liquiden US-Large-Caps duenn + kostenanfaellig; Mean-Reversion ist short-Vol (Tail-Risiko, braucht Vola-Abschalt-Filter). Vor jedem Echtgeld: im eigenen Walk-Forward Korrelation zu ORB + Netto-Edge nach Alpaca-Kosten beweisen. Voller Bericht: docs/research-zweite-strategie-2026-06-18.md.
DayPi-Tab der Webapp ausgebaut — Equity-Verlauf, Gesamt-P/L, Signal-Feed2026-06-18
2026-06-18: Live-Ansicht (DayPi-Tab der InvestPi-Webapp, static/index.html) erweitert. Neu: (1) Equity-Verlauf des Tages als gefuellter SVG-Chart (Daten lagen schon im Snapshot als equity_curve, wurden nur nie gezeichnet; Tagesstart-Linie = Equity minus Tages-P/L). (2) Neue Kennzahl Gesamt-P/L seit Start (vorher nur Tages-P/L). (3) Karte Letzte Signale = die juengsten Bot-Entscheidungen mit Einstieg/Stop/Ziel (signals aus dem Snapshot, vorher ungenutzt). (4) Abgeschlossen-heute zeigt jetzt Trefferquote + Uhrzeit. Alles aus bereits vorhandenen Snapshot-Feldern -> kein Backend-/snapshot.py-Umbau, kein Service-Neustart (statische Datei). Backup unter static/index.html.bak-*.
Umzug auf User daypi + Datenhygiene-Startlinie2026-06-18
2026-06-18: Projekt am 17.06. (mit anderer Instanz) auf eigenen User daypi unter /home/daypi/daytrader umgezogen (analog investpi) — /home/pi/daytrader ist Altlast. Dashboard- Generator auf die lebende DB umgebogen (Live-Zahlen froren sonst ein). Datenhygiene: Trades vor der Strategie-Angleichung (Trockenlaeufe 16.06. + Affen-Trades 17.06.: NOK/LNAI/ICCM/SOXS) als strategy=orb_prealign markiert, predictions als prealign — NICHT geloescht (echte Kontoereignisse, Historie bleibt). Auswertung/Self-Learning zaehlen erst ab eval_start_date 2026-06-18 (erste angeglichene Session). Nur saubere, repraesentative Daten fuer die Echtgeld-Entscheidung.
Live an Backtest angeglichen — Edge-Filter + liquide Universe (war auseinandergelaufen!)2026-06-17
2026-06-17: Kritischer Fund beim Pruefen, ob LIVE ueberhaupt die VALIDIERTE Strategie handelt — tat es NICHT. Drei Abweichungen: (1) Der Kern-Edge (OR-Volumen >= 2,2x 20-Tage-Median) wurde live gar nicht angewandt — der Loop sortierte nur nach rohem Volumen, rel_volume_min wurde ignoriert. (2) Universe: live handelte Alpacas Most-Actives = $3-7-Mikro-Caps (ICCM, LNAI, EHGO), die im Backtest (60 liquide Namen) NIE vorkamen. (3) Feed: Backtest SIP, live IEX. Folge: die Live-Daten massen eine ungetestete Variante, nicht die validierte Edge — und Papier-Fills auf illiquiden Namen schmeicheln am meisten. FIX (Option A): Live handelt jetzt die screen_universe (= Backtest-Universe) und berechnet relatives Volumen echt (heutiges OR-Volumen / 20-Tage-Median, Zaehler+Nenner beide IEX -> Ratio stimmig), Filter rel_volume_min greift, Top-N nach rel-Vol. Empirisch geprueft: SIP ist auf dem Gratis-Konto fuer aktuelle Daten gesperrt -> IEX-Historie (19 Handelstage) reicht fuer den Median. Test 2026-06-17: statt Mikro-Caps nun ROKU 3,8x / ABNB 3,4x / ADBE 2,7x. Offen/Caveat: Schwelle 2,2 wurde auf SIP getunt, auf IEX evtl. nachzukalibrieren, sobald Live-Daten da sind.
Sicherheits-Durchgang: Not-Aus, Retries, Fehler-Protokoll2026-06-17
2026-06-17: Drei Schutzmassnahmen Richtung Echtgeld-Reife. (1) NOT-AUS: Datei data/.KILL anlegen -> Live-Loop macht keine neuen Entries mehr; Schutz-Exits (Flat-before-Close, Daily-Loss) laufen bewusst weiter (kein Overnight-Risiko). Datei loeschen = wieder scharf. (2) RETRIES: Alpaca-Lese- Abfragen (Konto/Positionen/Clock/Quotes/Bars/ATR) werden bei transienten Haengern bis 3x wiederholt (exponentielles Backoff). Order-Aufgabe bewusst OHNE Retry — ein Wiederhol-Submit nach Timeout koennte eine Doppel-Order erzeugen. (3) FEHLER-PROTOKOLL: jeder Absturz des Live-Loops/Settle landet mit Zeitstempel in data/daypi_errors.log statt still zu verschwinden (der oneshot-Service hatte kein OnFailure -> Fehler waren bisher unsichtbar). Begruendung: ein still kaputtes System untergraebt die Datengrundlage, auf der die spaetere Echtgeld-Entscheidung beruht.
End-Ziel festgelegt: Vorstufe zu Echtgeld2026-06-17
2026-06-17 (Mert): DayPis Paper-Konto ist nur die Testphase, nicht Selbstzweck. Ziel ist Echtgeld-Handel, sobald die Zahlen ueber Wochen/Monate ueberzeugen. Folge fuer die Prioritaeten: Robustheit, Risiko-Bremsen und realistische Kosten/Fills wiegen ab jetzt schwerer als neue Features. Erst Track-Record sammeln (sauberes Ergebnis-Gedaechtnis steht seit settle.py), dann ein vorab definierter Go-Live-Maszstab, dann ggf. Echtgeld. Bewusst NICHT: die volle InvestPi-Maschine nachbauen, solange DayPi kaum Daten hat — das hiesse auf Zufall optimieren.
Auf eigenen Nutzer + GitHub-Deploy umgezogen (Echtgeld-Isolation)
2026-06-17: daypi laeuft jetzt unter eigenem System-Nutzer daypi in /home/daypi/daytrader (vorher User pi). Eigene Python-venv, alle 3 systemd-Dienste als User daypi, Web-App-Tab via Symlink /home/pi/daytrader heil gehalten. GitHub-Deploy: privates Repo mertoege/DayPi per SSH-Deploy-Key (kein Token im Klartext); Auto-Commit pusht nach GitHub (Off-Device-Backup + Verlauf), bewusst OHNE reset-Pull (kein Verlust lokaler Edits). Begruendung: beide Trading-Systeme zielen auf Echtgeld -> Abschottung je System ist wichtiger als Aufraeum-Optik.
Versionsverwaltung eingefuehrt (Git + Auto-Sicherung)
2026-06-17: DayPi hatte bisher KEINE Versionsverwaltung — Code-Aenderungen gingen sofort live, ohne Verlauf/Netz (anders als die Schwester investpi mit Git-Deploy). Jetzt: lokales Git-Repo in /home/pi/daytrader (.gitignore schliesst Secrets .alpaca.env + data/ aus) plus taeglicher Auto-Commit (systemd daypi-autocommit.timer, 03:43) -> Aenderungen nachvollziehbar und rueckrollbar. (HISTORISCH: hier stand zuerst "bewusst lokal belassen" — am 2026-06-17 REVIDIERT, siehe Eintrag oben: daypi wurde fuer Echtgeld-Isolation auf eigenen Nutzer + GitHub-Deploy umgezogen.)
Ergebnis-Speicherung gebaut (Ausstiege/Outcomes)2026-06-17
2026-06-17: Neues scripts/settle.py gleicht geschlossene Round-Trips aus Alpaca gegen die Einstiege ab und schreibt das reale Ergebnis dauerhaft in die DB: trades.pnl + status=closed sowie predictions-Outcome (P/L, return_pct, R-Vielfaches). Idempotent, je Symbol+Tag eindeutig, --date erlaubt Backfill. Verdrahtet: daypi_live.py legt bei jedem Entry eine predictions-Zeile an und ruft nach dem Flatten vor Close settle automatisch. Heutige 4 Trades validiert (ICCM +2059, NOK +377, SOXS -495, LNAI -1315; Netto +627) — exakt deckungsgleich mit der Live-Anzeige. Damit hat der Self-Learning-Loop endlich eine vollstaendige Outcome-Historie (vorher nur Einstiege).
GEPRUEFT: Trade-Recording der Einstiege ist sauber (kein Bug)erledigt
2026-06-17: Verdacht "ICCM fehlt in der DB" widerlegt. Alle 4 heutigen Einstiege (NOK, LNAI, ICCM, SOXS) stehen in daypi.db, die Alpaca-Order-IDs stimmen exakt ueberein (ICCM = Trade 7, oid 189764ca). daypi_live.py zeichnet jeden gefuellten Entry zuverlaessig auf.
Live-Kerzencharts je Trade2026-06-17
Jede offene Position zeigt in der Webapp einen Kerzenchart (Minuten-Kerzen aus Alpaca, Einstiegs- + Live-Kurslinie), aktualisiert alle 2s. Kerzendaten kommen ueber das Snapshot (daypi_public.json).
Live-Updates alle 2 Sekunden2026-06-17
Eigener Dienst (daypi-snapshot.service) frischt die Live-Zahlen in Marktzeit alle 2s; Webapp laedt im DayPi-Tab alle 2s nach (nur wenn offen+sichtbar). So kann man Kurse/P&L nahezu in Echtzeit mitverfolgen.
Webapp-Ansicht ausgebaut2026-06-17
DayPi-Tab zeigt jetzt: aktive Trades mit Live-Gewinn/Verlust, abgeschlossene Trades mit realem P/L, Hebel — live aus Alpaca (Snapshot mit Absturzsicherung, faellt sonst auf DB zurueck).
Erste Live-Session gelaufen2026-06-17
2026-06-17 15:35 CEST: DayPis erste echte Trades platziert (LNAI long, NOK short). Screener, ORB-Breakout, ATR-Stop und Hebel-Cap funktionieren live. Alpaca-API nach gestrigem Ausfall wieder gesund.
Harte Zahlen live aus config2026-06-17
Canvas liest DayPis Parameter (Hebel-Cap, Stops, Timer-Zeiten) direkt aus config.yaml — koennen nie veralten. Manifest haelt nur noch Text/Begruendung, keine doppelten Zahlen.
Hebel-Cap ≤ 2×2026-06-17
Brutto-Exposure-Bremse: Summe aller Positions-Notional ≤ 2× Equity (statt blind bis Broker-4×). Trimmt Positionsgröße, dann Stopp.
Manifest = Single Source of Truth2026-06-17
Aufbau/Status/Roadmap pro Projekt in manifest.yaml beim Code — Canvas liest es. Chat-Beschlüsse landen sofort hier.
Sim-zu-Live ist DER Test2026-06-17
Paper-Fills sind oft besser als echte. Erst Live-Paper-Forward-Test misst, ob die Edge die echten Fills hält.
Echtgeld-Kosten geklärt2026-06-17
Alpaca kommissionsfrei; nur winzige SEC/FINRA-Sell-Fees (~1,50 USD/Round-Trip). Echter Block = Slippage (im Backtest drin). PDT: ≥ 25k USD nötig.
Snapshot-Brücke zur Webapp2026-06-16
DayPi schreibt welt-lesbares daypi_public.json (nur DB-Lesen). /home/pi/daytrader auf 701 (Key bleibt 600). Webapp-Tab liest nur das JSON.
close_all gehärtet2026-06-16
Alpaca-Bulk-Endpoint 504t → Retry 4× + Einzel-Position-Fallback + Verifikation. Kritisch fürs sichere Flat-before-Close.
Offene Aufgaben für Mert
- Woechentliche Trade-Ergebnisse pruefen routine — Ergebnisse der Live-Paper-Sessions anschauen (Webapp, DayPi-Tab): laeuft die Strategie wie erwartet? Gibt es auffaellige Verlust-Tage oder fehlende Trades? Entscheiden, ob Parameter-Anpassung noetig ist.
- Go-Live-Maszstab fuer Echtgeld festlegen einmalig — Vorab definieren, welche Zahlen ueber welchen Zeitraum einen Wechsel von Paper auf Echtgeld rechtfertigen (z.B. positive Erwartung nach realistischen Kosten, Mindest-Trefferquote/Schnitt-R, max. Drawdown, Mindestanzahl Trades, Mindest-Laufzeit). Plus: Startkapital (PDT-Regel braucht >= 25k USD) und persoenliche Risiko-Grenze. Ohne vorab gesetzte Latte redet man sich Echtgeld sonst schoen.
Notizen
Stand Juni 2026: Fundament → Live-Paper steht, erste reale Session heute 15:30 CEST. Validierung: OOS-Sharpe 1,15, Win 50,6 %, +3,4 % in ~6 Wochen Backtest (robust, nicht overfit). Erwartungs-Messlatte (Backtest auf dem angeglichenen Stand, 120 T, 60 liquide Namen, 2026-06-17): mit Filter 205 Trades, Win 54,6 %, Ø +0,08R, +16,6 %, Sharpe 2,18, MaxDD −8 % — OHNE Filter −93,7 % (= der Filter IST die Edge). Achtung: Voll-Durchlauf, ehrlich eher OOS-Sharpe ~1,15 erwarten; live nutzt IEX statt SIP -> Auswahl weicht leicht ab. Self-Learning-Loop (Outcomes/Attribution) + Strategie-Portfolio sind die nächsten Schritte. Eigenes Paper-Konto — NICHT InvestPis. Codename umbenennbar.
PokéPi🟢 läuftPokéPi ist ein vollautomatischer Pokémon-Karten-Schnäppchenjäger. Er scannt rund um die Uhr eBay und Kleinanzeigen, vergleicht jeden Fund mit dem echten Marktpreis (Cardmarket) und schickt Mert per Telegram eine Kaufempfehlung — mit Foto, Rabatt und Feedback-Buttons. Das System lernt aus seinen Fehlern und wird mit jeder Vorhersage besser.
PokéPi ist ein vollautomatischer Pokémon-Karten-Schnäppchenjäger. Er scannt rund um die Uhr eBay und Kleinanzeigen, vergleicht jeden Fund mit dem echten Marktpreis (Cardmarket) und schickt Mert per Telegram eine Kaufempfehlung — mit Foto, Rabatt und Feedback-Buttons. Das System lernt aus seinen Fehlern und wird mit jeder Vorhersage besser.
Funktionsweise
- Scraping — alle 10 Min eBay Browse-API + Kleinanzeigen (8 Suchbegriffe, Duplikat-Filter)
- Prefilter — Preisspanne, Bilder, Listing-Alter, URL-Normalisierung
- Identifikation — Pokémon-TCG-API (Name, Set, Seltenheit) + Cardmarket Live-Preis (curl_cffi + FlareSolverr)
- Enrichment — Gemini Vision (Zustand/Grading) + Collector-Tier + Turnier-Relevanz + Sentiment-Score
- Math-Prefilter — Listing > Marktpreis × 0,90 → sofort SKIP ohne Claude (Kostenschutz)
- Claude-Bewertung — Sonnet: 48h-Preishistorie + Meta-Reviews + Hit-Rate-Muster → Verdict + fairer Preis
- Veto-Checks — Math-, Grading-, Alter-, Investment-Veto — korrigiert Halluzinationen automatisch
- Telegram-Alert — KAUFEN/INVESTIEREN → Foto + Rabatt% + Feedback-Buttons (Gekauft/Kein Interesse/Fehlalarm)
- Outcome-Track — nach ≥7 Tagen echten Marktpreis messen und mit der Vorhersage vergleichen
- Meta-Review — Do 03:00: Opus analysiert Fehleinschätzungen und passt die Bewertungslogik an
Automatisierungen
Preis-Snapshot (Cardmarket)täglich 06:00
Jeden Morgen um 06:00 holt das System für alle Karten im Inventar den aktuellen Tagespreis von Cardmarket — das günstigste verfügbare Angebot zählt als Marktwert. Das Ergebnis wird in der Preis-Datenbank gespeichert, damit Preiskurven und Trends sichtbar werden. Läuft einmal täglich, um das Cardmarket-Budget zu schonen.
Sentiment-Check (Reddit + Google Trends)täglich 08:00
Täglich um 08:00 schaut das System auf Reddit und Google Trends: Welche Karten werden gerade viel diskutiert? Gibt es einen Hype-Anstieg? Das Ergebnis fließt als Stimmungswert in die Claude-Bewertung ein — eine Karte, über die alle reden, ist anders einzuschätzen als eine vergessene.
eBay-Marktpreis-Snapshot3× täglich (07:00, 12:30, 19:00)
Dreimal täglich (07:00, 12:30, 19:00) sammelt das System über die offizielle eBay-Schnittstelle aktuelle Angebotspreise für alle Inventar-Karten. Für bereits bewertete Karten (z.B. PSA 10) wird gezielt nach dem Grading-Label gesucht. Die Werte landen in der Preis-Datenbank und geben ein realistisches Bild davon, was Karten am Markt gerade kosten.
CM-Watchlist-Scanner3× täglich (08:00, 13:00, 19:00)
Dreimal täglich (08:00, 13:00, 19:00) prüft das System jede Karte auf der Investment-Watchlist: Ist der günstigste Cardmarket-Preis gerade unter dem eingestellten Maximal-Kaufpreis? Gibt es auch auf eBay oder Kleinanzeigen ein passendes Angebot? Nur wenn der Preis wirklich stimmt und der Trend nicht nach unten zeigt, landet ein Telegram-Alert mit direktem Kauflink.
Event-Kalender-Alertstäglich 09:00
Täglich um 09:00 prüft das System den Pokémon-Turnierkalender und warnt 7, 3 und 1 Tag vor anstehenden Events per Telegram. Kurz vor großen Turnieren steigen Preise für Meta-Karten erfahrungsgemäß — der Alert gibt Mert rechtzeitig einen Hinweis.
Inventar-Überwachung (Kurseinbruch)täglich 12:05
Täglich um 12:05 vergleicht Claude Sonnet die aktuellen Cardmarket-Preise mit den gespeicherten Einstiegspreisen aller Inventar-Karten. Erkennt das System einen deutlichen Kurseinbruch bei einer gehaltenen Karte, schickt es sofort einen Telegram-Alarm — damit Mert reagieren kann, bevor der Verlust größer wird.
Freitags-Bericht (Verkaufsvorschläge)freitags 12:00
Jeden Freitag um 12:00 erstellt Claude Sonnet eine priorisierte Verkaufsliste für das Wochenende — welche Inventar-Karten sollten jetzt verkauft werden? Dabei fließen aktuelle Marktpreise, Hype-Werte und Plattform-Gebühren ein. Der Report kommt per Telegram und bereitet Mert auf den Whatnot-Livestream vor.
Outcome-Trackertäglich 02:00
Täglich um 02:00 sucht das System alle Kauf-Vorhersagen heraus, die mindestens 7 Tage alt sind und noch kein echtes Ergebnis haben. Es vergleicht den damaligen Listenpreis und das Claude-Urteil mit dem heutigen Marktpreis. So entsteht messbares Feedback: War die Einschätzung richtig oder falsch? Diese Daten sind die Grundlage des Lern-Loops.
Meta-Review (Opus Selbst-Reflexion)donnerstags 03:00
Jeden Donnerstag um 03:00 — aber nur wenn mindestens 30 gemessene Ergebnisse vorliegen — lässt Claude Opus die bisherigen Fehleinschätzungen Revue passieren. Es analysiert, bei welchen Quellen (eBay-Alerts, Inventar, Wochenberichten) und Konfidenz-Stufen das System am häufigsten daneben lag, und schreibt eine strukturierte Reflexion. Die Erkenntnisse fließen danach als Kontext in zukünftige Sonnet-Bewertungen ein — so wird das System Woche für Woche besser.
Wochenbericht (Opus Marktanalyse)sonntags 22:00
Jeden Sonntag um 22:00 erstellt Claude Opus einen tiefen Marktbericht: Wie hat sich das Inventar entwickelt? Welche Karten sind heiß, welche verlieren? Was lernt das System aus den Fehlern der Woche? Der Bericht landet als Datei und per Telegram-Zusammenfassung und dient als Grundlage für die Strategie der nächsten Woche.
Telegram-Callback-Prozessorjede Minute
Jede Minute fragt das System bei Telegram nach, ob Mert auf einen Kauf-Alert reagiert hat — also ob er einen der Buttons gedrückt hat (Gekauft, Kein Interesse, Fehlalarm). Sobald ein Klick eingeht, wird das sofort als Ergebnis gespeichert. Das ist der direkteste Weg, wie Merts Feedback ins Lern-System eingeht — kein Warten auf 7 Tage.
Cardmarket-Scraper Keepalive (Host)jede Minute (Host)
Jede Minute prüft ein kleines Wächter-Skript auf dem Pi, ob der Cardmarket-Scraper noch läuft. Läuft er nicht mehr, startet es ihn automatisch über den System-Dienst neu. So ist sichergestellt, dass Preisabfragen von Cardmarket nie lange ausfallen, ohne dass jemand eingreifen müsste.
Turnier-Check (Limitless TCG)montags 10:00
Jeden Montag um 10:00 lädt das System die neuesten Turnierergebnisse von Limitless TCG — einer Plattform, die offizielle Pokémon-Turniere auswertet. Es speichert, welche Karten gerade in erfolgreichen Decks (Top-8) auftauchen. Karten mit hoher Turnier-Relevanz bekommen in der Bewertung einen Bonus, da sie in der Regel stärker nachgefragt werden.
DB-Backup (Host)täglich 03:30 (Host)
Täglich um 03:30 erstellt ein Host-Skript Sicherungskopien beider Datenbanken (Inventar/Alerts und Preiszeitreihen) und packt sie platzsparend zusammen. Backups, die älter als 14 Tage sind, werden automatisch gelöscht. Zusätzlich sichert dasselbe Skript auch die AutoPi-Datenbank.
Disk-Cleanup (Host)sonntags 02:30 (Host)
Jeden Sonntag um 02:30 räumt ein Skript auf dem Pi auf: Log-Dateien über 5 MB werden archiviert, Archive älter als 14 Tage gelöscht. Außerdem werden aus der Datenbank veraltete Einträge entfernt — Scan-Protokolle älter als 90 Tage und bereits gesehene Angebote älter als 30 Tage. So bleibt der Pi nicht voll.
Daten & Datenbank
pokepi.db
Haupt-DB — Inventar, Kauf-Alerts, Claude-Vorhersagen (Kern des Lern-Loops), Watchlist, Feedback und Duplikat-Filter.
inventoryalertspredictionswatchlistseen_listingsalert_funnelfeedback_reasonspending_feedbacksealed_pricestelegram_state
prices.db
Preis-Zeitreihen — Cardmarket-Bulk-Preise, eBay-Verkaufspreise (echte Transaktionen), Snapshots und Karten-Metadaten-Cache.
cardmarket_bulk_pricesebay_sold_cacheprice_snapshotstcg_lookup_cachecondition_cache
Bewertungs-Logik
Math-Prefilterguard
Listing über 90% des Marktpreises → sofort SKIP, ohne Claude zu fragen. Spart Kosten und Zeit.
Context-Stackdecision
Sonnet bekommt 48h-Preishistorie, Opus-Wochenbericht, Sentiment, Meta-Reviews und aktuelle Hit-Rate-Muster als Kontext.
Konfidenz-Stufenmeasure
HIGH → KAUFEN ab >25% Rabatt · MITTEL → ab >15% · NIEDRIG → nur INVESTIEREN (kein sofortiger Kauf).
Verdict + fairer Preisengine
Sonnet gibt JSON zurück: verdict (KAUFEN/INVESTIEREN/SKIP), Begründung, adjusted_market_price (nach Grading-Abschlägen).
Math-Vetoguard
Listing teurer als der von Claude errechnete faire Preis → automatisch zu SKIP korrigiert. Halluzinations-Schutz.
Alter-Vetoguard
≥3 Tage alt: nur ab 40% Rabatt · ≥5 Tage: nur ab 50% · ≥7 Tage: immer SKIP (Angebot wahrscheinlich fehlerhaft).
Grading-Korrekturengine
PSA/CGC/BGS-Zertifikat erkannt → Grading-Premium wird in den fairen Preis eingerechnet.
Investment-Vetoguard
Listing über max_buy × 1,05 → SKIP. Schützt vor Käufen außerhalb des Budgets.
Kosten-Gateguard
Budget-Deckel im Alert-Worker (2€ werktags / 8€ WE, 50€/Monat). Überschreitung → Sonnet-Call wird blockiert.
Daten & Quellen
eBay Browse-API
offizielle Schnittstelle für Live-Listings + Sold-Listings (echte Transaktionspreise)
Kleinanzeigen
lokale Angebote (Async-Scraping)
Cardmarket
Scraping via curl_cffi + FlareSolverr + BrightData-Proxy (Cloudflare-Bypass), 7d-Cache
Pokémon-TCG-API
Karten-Identifikation (Name, Set, Seltenheit), Fallback bei jap. Sets via Cardmarket-URL
Reddit + Google Trends
Hype-/Sentiment-Score (täglich 08:00)
Limitless TCG
Turnier-Meta (Deck-Anteile, Top-8), wöchentlich Mo 10:00
Wer/was arbeitet
Claude Sonnet
Deal-Bewertung im Alert-Loop + Daily/Friday-Reports
Claude Opus
Wochenbericht (So 22:00) + Meta-Review / Fehleranalyse (Do 03:00)
Gemini Vision (Flash)
{'Kartenfotos auswerten': 'Zustand, Grading (PSA/CGC/BGS), Fälschungsverdacht'}
Alert-Worker
Dauerschleife Scrape→Filter→Claude→Telegram, Kostendeckel per Budget-Gate
Veto-System
Math/Grading/Alter/Investment-Checks korrigieren Claude-Verdicts automatisch
Telegram-Bot
Push-Alerts + Feedback-Buttons (Gekauft/Kein Interesse/Fehlalarm)
Technik
SprachePython 3.11 · FastAPI · SQLite (WAL) · httpx
FrontendReact 18 + Vite 5 · PWA · Mobile-First · Custom CSS (kein UI-Framework)
ContainerDocker Compose · 6 Container (backend, alert-worker, cron-worker, frontend, flaresolverr, webterminal)
Schedulingsupercronic (12 Container-Cron-Jobs) + Host-Crontab (Backup, Cleanup)
KIAnthropic SDK (Sonnet/Opus) · Google Gemini Vision
Scrapingcurl_cffi · FlareSolverr · Playwright · BrightData-Proxy-Rotation
Pfad/home/pi/pokepi · User pi · kein Auto-Pull auf Manifest
Roadmap — Produktiv & Self-Learning aktiv
✅ Kern-System
Scraping & Dedupfertig
eBay Browse-API + Kleinanzeigen, 8 Suchbegriffe, URL-Normalisierung, seen_listings-Filter.
Karten-Identifikationfertig
Pokémon-TCG-API + Cardmarket-Live-Preis (curl_cffi + FlareSolverr + Proxy-Rotation).
Claude-Bewertung + Veto-Systemfertig
Sonnet bewertet, 5 Veto-Checks korrigieren automatisch Fehleinschätzungen.
Telegram-Alerts + Feedback-Loopfertig
Foto + Rabatt + Buttons (Gekauft/Kein Interesse/Fehlalarm). Callbacks jede Minute.
FastAPI-Backend + React-PWAfertig
70+ Endpoints, Mobile-First, Docker Compose (6 Container), supercronic.
✅ Self-Learning-Loop
Predictions-Trackingfertig
Jeder Sonnet-Call speichert structured output (Karte, Preis-Prognose, Konfidenz, Kosten).
Outcome-Trackerfertig
Täglich 02:00 — Vorhersagen nach 7 Tagen mit echtem Marktpreis vergleichen.
Opus-Meta-Reviewfertig
Do 03:00 — Opus reflektiert Fehleinschätzungen je Quelle/Konfidenz und schreibt Reviews.
Few-Shot-Feedbackfertig
Meta-Reviews fließen als Kontext in den nächsten Sonnet-Prompt → kontinuierliche Verbesserung.
🔄 Laufende Verbesserungen
System-Optimizer (montags)aktiv
Passt Schwellwerte und Prompts autonom an — basierend auf Outcome-Daten.
Auto-Merge Optimizer-Vorschlägegeplant
Kleinere Optimizer-Empfehlungen sollen automatisch übernommen werden (aktuell noch manuell).
⬜ Potenzielle Erweiterungen
Webterminal auslagernoffen
Läuft im pokepi-Repo, ist aber projektübergreifend. Mittelfristig nach /home/pi/tools/ auslagern.
Backblaze B2 Backup reaktivierenbei Bedarf
Restic-Backup nach B2 ist deaktiviert (lokales Backup reicht derzeit). Bei Bedarf reaktivieren.
Entscheidungs-Log
Marktwert-Fix EINGEHÄNGT & LIVE (idProduct in Alert-Pipeline)2026-06-19
2026-06-19: idProduct-Marktwert in die Alert-Pipeline eingehängt und deployed. (1) Lokaler CardTrader-Barcode-Katalog gebaut (scripts/build_cardtrader_catalog.py → Tabelle cardtrader_catalog, 72.348 Karten/842 Sets, 89,7% mit CM-Barcode). (2) Offizielle CM-Preisliste reaktiviert (cron täglich 05:30, ~70k Karten, kein Scraping). (3) services/idproduct_pricing.py löst Karte über Nummer+Name+Sprache+Rarität auf den exakten Cardmarket-idProduct auf → Preis aus offizieller Liste. (4) In market_price.get_cardmarket_prices als PRIMÄRPFAD eingehängt, Fallback auf Scraper wenn nicht auflösbar (additiv, keine Regression), Kill-Switch ENV USE_IDPRODUCT_PRICING=0. Vorher/Nachher an 12 echten Alert-Karten: 8 via idProduct mit korrigierten Werten (alte Fehlalarme durch falsche Karte aufgedeckt, z.B. Garchomp 30→6,5€; Blastoise 116→150€ = korrekt höher), 4 sauberer Scraper-Fallback. alert-worker neu gebaut+gestartet (mountet Code nicht → COPY ins Image). Ergebnis: richtige Karte + verlässlicher Preis + exakte Filter-URL, deutlich weniger Scraping. Offen: Katalog-Refresh-Zeitplan; optional Live-Tiefstpreis als 2. Stufe auf der idProduct-Seite.
Marktwert-Wurzelfix — idProduct-Barcode statt CM-Suche (BEWIESEN, 2026-06-18)2026-06-18
2026-06-18: Kernproblem von PokéPi (ständig falsche Cardmarket-Karte / falsche Filter) auf die Wurzel zurückgeführt: Die Preis-Pipeline SUCHT Cardmarket per Name/Nummer (fuzzy → falsche Variante, Sets vermischt) und die Filter (Sprache/Kondition/sellerCountry) wirken NUR auf einer konkreten Produktseite, nicht auf Suchergebnissen → verpuffen. LÖSUNG (Mert: erst beweisen, dann bauen): jeder Karte ihren Cardmarket-Barcode (idProduct) geben. Quelle = CardTrader-Blueprint-Export (Set+Nummer+Variante → card_market_ids = CM idProduct, variantengenau, gratis API), Preis = offizielle CM-Preisliste (jobs/cardmarket_csv_import: products_singles_6 + price_guide_6 → 70.505 Karten idProduct→Trend/Low/Avg, 4s, OHNE Scraping; war deaktiviert, reaktivieren). BEWEIS (scripts/cardtrader_idproduct_proof.py): 10/11 gültige Testkarten exakt richtige Variante + offizieller Preis (Squirtle normal 0,02€ vs Art Rare 27€/96€; Dark Dragonite Holo#5 vs Rare#22). 1 Lücke: CardTrader hat nicht für jede Karte eine CM-ID (z.B. Mew ex 151) → Fallback nötig (offizieller CM-Katalog per Name+Expansion / Bildabgleich / Scraper als letzter Ausweg). NÄCHSTER SCHRITT: idProduct-Auflösung + offizielle Preisliste in die Alert-Pipeline integrieren, Scraper nur noch für Live-Tiefstpreis auf der EXAKTEN Produktseite. Siehe [[feedback_price_source_filter]].
CardTrader-API getestet — filterbar & EUR, aber DE-Liquidität zu dünn2026-06-18
2026-06-18: CardTrader (EU-Marktplatz) mit echtem Token gegen Watchlist-Karten getestet (scripts/test_cardtrader.py). ERGEBNIS: Erfüllt — anders als TCG-Preis-APIs — Merts Filter-Regel: Preise in EUR, pro Angebot Sprache + Kondition + Verkäuferland (country_code) + graded-Flag, und Varianten sind SEPARATE Blueprints (Squirtle Common #007 vs Illustration Rare #170) je mit eigener card_market_ids → exakt auf die Cardmarket-Produktseite mappbar. API offen (Bearer-Token aus Konto, keine Freigabe), schnell, 842 Pokemon-Expansions. ABER: deutsche Verkäufer zu dünn — Squirtle Art Rare EN nur 2 DE-Angebote (DE+NM ~100€ vs CM ~150€), Art Rare JP 0 DE-Angebote, Mew ex 0 DE-Angebote; Sprachen mischen sich innerhalb eines Blueprints (JP-Blueprint enthielt KR-Angebot) → Sprachfilter nötig. FAZIT: kein Cardmarket-Ersatz (DE-Tiefe fehlt), aber brauchbar als (a) Preis-Cross-Check und (b) EU-weite Zusatz-Dealquelle, falls Kauf aus anderen EU-Ländern ok. Noch NICHT integriert — Entscheidung offen.
Preisquelle muss filterbar sein — TCG-Preis-APIs verworfen2026-06-18
2026-06-18: Festhalten (Mert hat es schon vielen Instanzen gesagt): TCG-basierte Preis-APIs (TCGdex, pokemontcg.io/Scrydex, Aggregatoren mit Cardmarket-Preis-Tabelle) sind als Preisquelle UNGEEIGNET und wurden bereits getestet+verworfen. Grund: dieselbe Karte hat viele Ausprägungen mit teils stark abweichenden Preisen — Variante/Print, Sprache (JP oft 50–70% günstiger = die Arbitrage), Kondition, Grading, und Verkaufsort Deutschland. TCG-APIs liefern nur EINEN Aggregatwert pro Karte und können danach NICHT filtern → falsche Werte → falsche KAUFEN/SKIP. Cardmarket bleibt Preisquelle via Scraper, weil nur die echte CM-Produktseite filtern kann (sellerCountry=7 DE, language=, minCondition=, exakte idProduct-Variante). Alternativquelle nur, wenn sie dieselben Filter + Live-Tiefstpreis bietet. TCGdex nur für Karten-Daten + idProduct, nie als Preisquelle.
Watchlist-Scanner (eBay/KA) — Dauer-Spam + falscher CM-Link behoben2026-06-18
2026-06-18: Zwei Bugs im cm_watchlist_scanner Phase 2 gefixt. (1) Die 12h-Wiederhol-Sperre verglich UTC-Zeitstempel (datetime('now')) gegen einen Cutoff aus Python datetime.now() (Ortszeit, +2h) — Fenster faktisch ~10h, dadurch wurde dieselbe Anzeige (z.B. "Squirtle Art Rare @ 34,99€") im 08- und 19-Uhr-Lauf erneut gemeldet, teils täglich. Cutoff jetzt SQLite-seitig (beide Seiten UTC). Zusätzlich neue Dedup pro Anzeige-URL (cm_wl_seen_listings), damit eine persistente Anzeige nur 1× rausgeht. (2) Der Cardmarket-Link wurde stur von der Watchlist-Karte übernommen, auch wenn die eBay-Anzeige eine andere Variante/Set war → falsche Karte. Jetzt: Kartennummer der Anzeige (Titel/Gemini) muss matchen; konkreter Produkt-Link nur wenn verifiziert, sonst ehrlicher CM-Suchlink. Mert-Entscheid: reparieren statt eBay/KA-Teil abschalten.
Manifest neu geschrieben (Canvas-Rewrite)2026-06-17
2026-06-17: Manifest vollständig neu strukturiert nach dem Canvas-Schema. Quellen: Dossier (pokepi.md Abschnitt B) + CLAUDE.md + Code-Verifikation. Alert-Worker-Takt auf 10 Min korrigiert (war im Dossier fälschlich als 15 Min angegeben), Container-Zahl auf 6 bestätigt (6 Services in docker-compose.yml). tasks:-Block 1:1 erhalten.
Cardmarket-Scraper läuft auf dem Host (nicht im Container)Architektur
2026-06-17: Läuft als systemd-Service (cardmarket-scraper.service) direkt auf dem Pi, nicht im Docker-Compose. Grund: Playwright + curl_cffi + Unix-Socket brauchen Host-Zugriff. Budget-Gate 500 Requests/Tag.
Zwei SQLite-DBs (WAL) statt einerArchitektur
Trennung von Transaktions-DB (pokepi.db) und Preis-Zeitreihen (prices.db) für saubere WAL-Parallelität und einfachere Backups.
5 Veto-Checks gegen Claude-HalluzinationenArchitektur
Claude kann irren — deshalb überschreiben Math-Veto, Grading-Korrektur, Alter-Veto, Investment-Veto und Multi-Source-Veto das Verdict automatisch. Menschliche Überprüfung nur noch für KAUFEN-Alerts nötig.
Budget-Gate im Alert-WorkerArchitektur
2€ werktags / 8€ WE / 50€ Monat. Sonnet-Call wird blockiert wenn Limit erreicht. Schützt vor Runaway-Costs.
Gemini Vision statt eigenes Modell für GradingArchitektur
Google Gemini Flash (Free Tier, 18 RPD Limit) erkennt Kartenzustand und Grading-Labels aus Fotos. Günstig genug für den Use-Case, kein eigenes Modell nötig.
Webterminal im pokepi-Repo (kurzfristig)Tech-Schuld
webterminal.py + Dockerfile.webterminal leben im pokepi-Repo, weil docker-compose.yml sie direkt baut. Eigentlich projektübergreifend — Auslagerung nach /home/pi/tools/ ist mittelfristig geplant, aber nicht dringend.
Offene Aufgaben für Mert
- Telegram-Alerts beantworten routine — Wenn PokéPi eine Kaufempfehlung per Telegram schickt, die Buttons drücken (Gekauft / Kein Interesse / Fehlalarm). Ohne dieses Feedback lernt das System nicht dazu.
- Empfohlene Karte auf eBay/Kleinanzeigen kaufen routine — Bei einem KAUFEN-Alert das Angebot auf eBay oder Kleinanzeigen aufrufen, bezahlen und die Karte bestellen. Das Geld muss Mert selbst ausgeben — das kann das System nicht.
- Gekaufte Karte ins Inventar eintragen routine — Nach dem Kauf die Karte manuell im PokéPi-Dashboard als "gekauft" einpflegen (Kaufpreis, Zustand). Nur dann taucht sie im Inventar auf und wird für Preisverläufe getrackt.
- Karte verkaufen und als verkauft markieren routine — Wenn der Friday-Report Verkaufsvorschläge liefert oder eine Karte im Wert gestiegen ist, das Angebot selbst einstellen (eBay/Kleinanzeigen) und danach im Dashboard als verkauft markieren.
Notizen
PokéPi ist vollständig autonom und self-learning. Cardmarket-Scraper läuft auf dem Host (Unix-Socket, systemd), nicht im Container — das ist der einzige Host-Dienst neben Backup und Status-Bus. Besonderheit des Lern-Loops: Opus reflektiert nur wenn mind. 30 Outcomes vorhanden sind (sonst zu wenig Datenbasis). AutoPi-Backups landen fälschlich im pokepi-Backup-Ordner (scripts/backup_db.sh sichert beide DBs) — technische Schuld, die noch bereinigt werden sollte.
Social & Content2
InstaPi🟢 läuftVollautomatische Social-Media-Maschine fuer zwei KI-Charaktere (Mila und Riley). Das System erfindet Bild-Ideen, laesst Higgsfield Soul 2.0 die Fotos generieren, prueft sie per Claude-Vision, laesst Mert das Beste auswaehlen und postet zeitgesteuert auf Instagram — und lernt jede Woche, welche Bild-Kategorien besser ankommen.
Vollautomatische Social-Media-Maschine fuer zwei KI-Charaktere (Mila und Riley). Das System erfindet Bild-Ideen, laesst Higgsfield Soul 2.0 die Fotos generieren, prueft sie per Claude-Vision, laesst Mert das Beste auswaehlen und postet zeitgesteuert auf Instagram — und lernt jede Woche, welche Bild-Kategorien besser ankommen.
Funktionsweise
- Ideation — Claude erfindet Szene und schreibt Bild-Auftrag; Kategorien werden nach gelernten Gewichten ausgewaehlt
- Generierung — Higgsfield Soul 2.0: 3 Slides x 2 Bildkandidaten je Slide
- Quality-Check — Claude-Vision prueft Gesicht / Outfit / Anatomie — lieber ablehnen als riskieren
- Auswahl — Mert waehlt in der Webapp (Port 8088) das beste Bild je Slide aus → wird Carousel
- Caption — Claude schreibt Caption + Hashtag-Set nach Kategorie + AI-Label
- Posten — Instagram Graph-API (Carousel / Story / Einzel-Post)
- Kommentar-Antworten — Claude beantwortet Kommentare 3x taeglich (9 / 14 / 21 Uhr)
- Analytics — Instagram Graph-API liefert Likes / Reach / Saves / Impressions je Post
- Lernen — woechentlich: Kategorie-Gewichte ±20% anpassen — was gut lief bekommt mehr Chance
Automatisierungen
Mila Carousel-Postalle 2 Tage, 19:xx Uhr
Alle zwei Tage um 19 Uhr startet die vollständige Produktions-Pipeline: Claude erfindet eine Szene, Higgsfield generiert Bildkandidaten, Claude-Vision prüft die Qualität, Mert wählt in der Webapp sein Favorit, Claude schreibt die Caption — und die Bilderserie wird automatisch auf Instagram veröffentlicht.
Mila Story (5×)13 / 14 / 16 / 18 / 21 Uhr
Fünfmal täglich (13, 14, 16, 18, 21 Uhr) wird automatisch die nächste Story aus dem vorbereiteten Story-Vorrat gepostet. Die Uhrzeit variiert leicht (+/- einige Minuten), damit es nicht maschinenhaft gleichförmig wirkt.
Kommentar-Antworten9 / 14 / 21 Uhr
Dreimal täglich (9, 14, 21 Uhr) liest das System alle neuen Kommentare unter Milas Posts und lässt Claude eine passende Antwort im Charakter-Stil schreiben. Die Antworten werden direkt über die Instagram-API abgeschickt — ohne dass Mert etwas tun muss.
Daily Analytics + Gewicht-Updatetäglich 22:xx Uhr
Jeden Abend um 22 Uhr holt das System Likes, Reichweite, Saves und Impressionen für jeden Post aus der Instagram-API und speichert sie in der Datenbank. Danach berechnet es sofort, welche Bild-Kategorien heute gut oder schlecht liefen, und passt die Zufalls-Gewichte an: starke Kategorien bekommen +20 %, schwache -20 %.
Weekly Report + neue PromptsSonntag 10:xx Uhr
Jeden Sonntag um 10 Uhr zieht das System eine Wochenbilanz (Posts, Likes, Reichweite, beste Kategorie), schickt sie als Zusammenfassung per Telegram an Mert und lässt Claude gleichzeitig einen frischen Satz Bild-Aufträge für die Topkategorie der Woche generieren. So hat die Pipeline immer neue Ideen im Vorrat.
Higgsfield Token-Keepalivealle 4 Stunden (:30)
Alle 4 Stunden (2, 6, 10, 14, 18, 22 Uhr, jeweils :30) erneuert das System im Hintergrund den Anmelde-Token für Higgsfield. Das verhindert, dass die Bildgenerierung mitten in einer Produktion wegen abgelaufenem Login abbricht — Mert merkt davon nichts.
Täglicher Reminder an Merttäglich 9:30 Uhr
Jeden Morgen um 9:30 Uhr schickt das System eine kurze Telegram-Nachricht an Mert mit dem heutigen To-do (z. B. Bilder auswählen, manuelles Engagement). So vergisst er keine Aufgabe, die der Bot nicht allein erledigen kann.
Fanvue Chat-Botalle 10 Min — pausiert (wartet auf OAuth)
Alle 10 Minuten prüft der Bot ungelesene Nachrichten in Rileys Fanvue-Postfach und beantwortet sie mit Claude im Charakter-Stil. Der Job schläft aktuell, weil die einmalige OAuth-Freigabe durch Mert noch aussteht — sobald er sich einmal einloggt, läuft der Bot vollautomatisch.
Reddit-Poster (Riley)19:xx Uhr — schläft (keine Creds)
Jeden Abend um 19 Uhr soll der Bot automatisch einen Beitrag in konfigurierten Subreddits veröffentlichen — mit Bild und Caption im Riley-Stil. Der Job schläft noch, weil Reddit-Zugangsdaten und Subreddits noch nicht in der Konfiguration eingetragen sind.
X-Poster (Riley)19:xx Uhr — schläft (keine Creds)
Ähnlich wie Reddit — jeden Abend um 19 Uhr einen Post auf X/Twitter. Auch dieser Job wartet darauf, dass die X-Login-Daten in der Konfiguration eingetragen werden, bevor er aufwacht.
Daten & Datenbank
instapi.db
Alle Post-Daten, Prompt-Logs (mit QC-Verdict) und Analytics je Post.
post_historyprompt_historypost_insights
category_weights.json
Gelernte Kategorie-Gewichte fuer Riley und Mila (data/riley/ + data/mila/). Werden woechentlich automatisch angepasst.
picker_learning.json
Merts Bild-Auswahlhistorie — das System lernt, welche Bilder er bevorzugt.
qc_feedback.json
Entscheidungshistorie des Quality-Check — welche Bilder wurden abgelehnt und warum.
Produktions-Pipeline
1 · Prompt-Generatorservices/prompt_generator.py
Claude erfindet Szene + schreibt Higgsfield-Auftrag. Kategorie wird nach gelernten Gewichten ausgewaehlt (haeufiger was gut lief).
2 · Bildgenerierungservices/higgsfield.py
Higgsfield CLI wird aufgerufen — 3 Slides x 2 Kandidaten. Bilder landen lokal.
3 · Quality-Checkservices/quality_check.py
Claude-Vision prueft jedes Bild — Anatomie, Gesicht, kein doppelter Mensch. Sehr streng — lieber ablehnen.
4 · Mert waehlt ausservices/picker.py
Webapp (Port 8088) zeigt die besten Bilder je Slide. Mert tippt auf sein Favorit. System merkt sich seine Praeferenzen.
5 · Caption + Hashtagsservices/caption.py
Claude schreibt Caption + waehlt passendes Hashtag-Set nach Kategorie.
6 · Postenservices/instagram.py
Instagram Graph-API veroeffentlicht das Carousel (oder Story / Einzel-Post).
7 · Analytics + Lernenservices/analytics.py
Taeglich 22:00 werden Likes / Reach / Saves geholt und Kategorie-Gewichte angepasst: +20% fuer Top-Performer, -20% fuer schwache Kategorien.
Content-Generatoren
content_factorymoviepy · librosa
Psychologische Promo-Reels: 7 Trigger-Formate (pov_story, hot_take, late_night, send_this, before_after …). Fuer Windows-PC gebaut.
reel_creatorstable_whisper
Reel-Montage aus Video-Clips + Song + Hook + Lyrics (Whisper-Synchronisation).
lyrics_videofaster-whisper
Karaoke-Videos — Wort-fuer-Wort-Untertitel synchron zur Musik.
lyrics_cardPIL
Statische Lyrik-Grafiken in 4 Styles (Gradient, minimal, textured, backdrop).
audiogramlibrosa
Audio-Visualizer — Waveform, Bars oder Spectrum als animiertes Video.
mv_teasermoviepy · Claude
Musikvideo-Teaser in 6 Styles; Hook + Caption werden automatisch von Claude generiert.
ReelForgeWindows-PC
Interaktiver Reel-Editor fuer den Windows-PC (pywebview). Quellcode als Backup unter scripts/reelforge/ auf dem Pi — wird per scp uebertragen, laeuft dort mit run.bat.
Accounts / Charaktere
Milaaktiv — IG
Reaktiviert 2026-06-15. Postet alle 2 Tage ein Carousel + 5 Stories taeglich. Aktuell fuehrende Kategorien: freaky_creative 39% · flirty_outfit 28% · dark_lifestyle 22%. Lernloop aktiv.
Riley (Instagram)pausiert — Relaunch
Pausiert — IG-Account Jun 2026 trotz sauberem Warmup geflaggt (Selfie-Verifizierung). Neuer Account muss am PC in eigenem Browser-Profil erstellt werden (nach dem Reddit/TikTok-Test).
Riley (Fanvue)wartet auf OAuth
Monetarisierung ueber Fanvue (Chat / PPV / Girlfriend-Experience). Chat-Bot fertig gebaut, wartet auf OAuth-Freigabe durch Mert. Volle Strategie: Ansicht "Riley — Relaunch" im vorherigen Manifest erhalten geblieben.
Riley (Reddit / X)konfigurieren
Services vorhanden (reddit_poster.py, x_poster.py), schlafen noch — keine Zugangsdaten und Subreddits eingetragen. Werden nach dem Konzept-Test aktiviert.
Daten & Quellen
Instagram Graph-API
Posten + Insights (Likes / Reach / Saves / Impressions)
Higgsfield Soul 2.0
KI-Bildgenerator; Soul-ID je Charakter fuer konsistentes Aussehen
Claude / Anthropic
Prompt-Schreiben, Bild-Qualitaetspruefung (Vision), Captions, Kommentar-Antworten
Fanvue API
OAuth2 PKCE — Chat-Bot + PPV-Verkauf (wartet auf Freigabe)
Telegram-Bot
Alerts und Feedback-Kanal fuer Mert
Playwright
Browser-Automation (TikTok-Engagement / Reddit / X — teils manuell / teils schlaeft)
category_weights.json
Gelernte Kategorie-Gewichte je Charakter (Riley / Mila)
picker_learning.json
Merts Bild-Auswahlhistorie — System lernt seine Praeferenzen
Wer/was arbeitet
Higgsfield CLI
Text-to-Image im Docker-Container (Soul V2, 2K-Qualitaet)
Claude Sonnet
Prompt-Generator / Caption-Writer / QC-Vision / Kommentar-Antworten
APScheduler
Zeitsteuerung aller Jobs (async, Europe/Berlin)
content_factory & Co.
7 Scripts fuer Reels / Videos / Cards (auf dem Pi als Read-Only eingehaengt)
Playwright-Sessions
TikTok-Engagement + (kuenftig) Reddit / X
Mert (Bild-Auswahl)
waehlt das Finale-Bild je Slide in der Webapp aus
Technik
RuntimeDocker Compose · Python 3.13 · FastAPI auf Port 8088
BildgenHiggsfield CLI (Soul V2, 2K)
SchedulerAPScheduler (async, Europe/Berlin)
VideoFFmpeg · moviepy · faster-whisper · librosa
Browser-AutomationPlaywright (Chromium headless)
DatenbankSQLite WAL — data/db/instapi.db
Config.env-Datei (nie ins Git), docker-compose.yml
Pfad/home/pi/instapi · User pi
Roadmap — instapi
Fertig — Mila-Pipeline
Docker-Container + FastAPIfertig
Backend laeuft stabil auf Port 8088, APScheduler steuert alle Jobs.
Prompt → Bild → QC → Postfertig
Vollstaendige Pipeline von Claude-Prompt ueber Higgsfield bis Instagram Graph-API.
Merts Bild-Auswahl (Webapp)fertig
Webapp zeigt Kandidaten, Mert waehlt, System lernt seine Praeferenzen.
Kommentar-Antwortenfertig
Claude beantwortet Kommentare 3x taeglich automatisch.
Lernloop (Kategorie-Gewichte)aktiv
Taegl. Analytics-Pull + woechentliche Gewichts-Anpassung ±20% laufen stabil.
Mila reaktiviert2026-06-15
Seit 2026-06-15 wieder aktiv nach Pause. Lernloop greift.
Laeuft — Riley-Relaunch
USP-Entscheidung getroffenentschieden
"Self-aware AI Girlfriend" als Primaer-Wette, Flugbegleiterin/GFE als Fallback.
Reddit/TikTok-Konzept-TestTODO — Mert
Beide Konzepte parallel testen (~2-3 Wochen), Sieger → neuer IG-Account.
Fanvue OAuth freigebenTODO — Mert
Einmalig http://[Pi-IP]:8088/fanvue/auth aufrufen, einloggen → Chat-Bot laeuft automatisch.
Neuen Riley-IG-Account anlegennach Test
Am PC in dediziertem Browser-Profil erstellen (nach dem Test + Warmup), dann Graph-API anbinden.
Geplant — Erweiterungen
.env-Luecken fuellengeplant
FANVUE_URL, REDDIT_SUBREDDITS_JSON, Reddit-Creds, X-Creds eintragen, damit die schlaefenden Poster aufwachen.
Manuelles Engagement (woechentlich)Mert-Aufgabe
Echte Kommentare auf groessere Nischen-Accounts — signalisiert Instagram echte Aktivitaet.
TikTok-Engagement (Riley)geplant
Standalone-Skripte (tiktok_engage.py) fuer gezielte Interaktion — erst nach Konzept-Test.
Fanvue PPV-Funnelnach OAuth
Chat-Bot aktiv → automatische PPV-Nachrichten und Whale-Engagement.
Entscheidungs-Log
Experiment „echtes Maedchen in Comic-Welt"-Slides (NICHT als Hauptcontent festgelegt)2026-06-22
Status: EXPERIMENT, noch nicht committet — erst auf TikTok/Reddit testen (zieht es Reichweite + Fanvue-Klicks?), dann entscheiden ob Haupt-, Neben- oder kein Content. Riley ist ein Fanvue-Model: jeder Post = Funnel (Reichweite → Begehren → Klick zu Fanvue/Chat/PPV), kein Selbstzweck. Look-Idee: serialisierte GFE-Story „Long-distance mit dir", Riley bleibt 100% Foto, NUR die Umgebung ist echtes Comic. Pipeline: (1) Riley SCHAUSPIELERND generieren (Soul V2, candid/echte Emotion, kein Posieren) → (2) dasselbe Bild per img2img (nano_banana_2, 9:16) in echtes Comic umzeichnen → (3) echte Riley per rembg deckungsgleich drueberlegen (perfekte Integration, kein Photoshop-Look) → (4) Hook-Text + Comic-SFX + Panel. Verworfen: Comic-Sprechblase/Filter nur ueber Foto („nicht comic genug"), Riley in separaten Comic-Raum kopieren („photoshop-maessig"). Jede Episode endet mit „red mit mir" → Funnel in den Chat. Offen: Daumen-Stopper-Punch (Hooks/Bewegung) noch zu schaerfen. Warum: Story bindet (Wiederkehr); echtes-Foto-in-Comic = unverwechselbar + nicht kopierbar; img2img-Comic statt Filter sieht wirklich gezeichnet aus; gleiche Bildquelle = saubere Integration.
Riley-USP „Self-aware AI Girlfriend"2026-06-17
Primaer-Wette — Riley weiss, dass sie AI ist, und will fuer „dich" echt werden; Fallback Flugbegleiterin/GFE. Warum: Niche-Premium + wachsender AI-Companion-Markt ($2,9 Mrd.) → AI-Label wird zum Feature statt Nachteil.
Riley-Reddit nur verifizierungsfreie Subs2026-06-20
Account-Auswahl: nur Subs OHNE Schild-Foto-Verifizierung (Start: r/OnlyFansPromotions, r/OnlyFans101 — verifizierungsfrei, Links erlaubt, niedrige Karma-Huerde). Warum: KI-Account kann das Verifizierungs-Foto (Schild mit Username/Datum) nicht liefern → das ganze GoneWild- Universum (gonewild, RealGirls, verifiedfeet) faellt weg. Nischen-Subs (curvy/amateur) erst spaeter dazu, je Sub Regeln einzeln pruefen.
Telegram-Tagescoach mit Auto-Umschaltung2026-06-20
Der tägliche 9:30-Reminder (reminders.py) wechselt automatisch vom Warmup-Text in den Bot-Phasen-Text, sobald der Auto-Poster scharf ist (REDDIT_SUBREDDITS_JSON gesetzt). Bot-Text: Pi postet automatisch, Mert macht Engagement (Kommentare/DMs echt beantworten) + Fanvue-Verkauf. Karma-Zeile ist vorbereitet (liest data/reddit_karma.json) — Befüllung per Pi-Login erst in der Bot-Phase (Scraper noch zu bauen). Warum: kein manuelles Umstellen nötig, ein Schalter (Subreddits) steuert Poster UND Coach. Warmup-Detail: Kommentar-Tage sagen NICHT zum Posten auf; nur an festen Selfie-Tagen (Plan: Tag 4/8/12) wird gepostet — und das Bild kommt automatisch als Datei (volle Qualität) per send_document mit (jedes Selfie genau 1x → kein Wiederholungs-Spam).
Reddit erst Warmup, dann Auto-Poster2026-06-20
Auto-Poster bleibt aus (REDDIT_SUBREDDITS_JSON leer), bis der Account 1–2 Wochen manuell aufgewaermt ist (Kommentare/Karma). Warum: neuer Account + sofort Werbung = Spam-Muster → Shadowban (haeufigster Sperr-Grund). Bot kann nur Bilder posten, nicht kommentieren — Warmup ist Handarbeit. Subreddit-Liste liegt als auskommentierte Vorlage in .env bereit.
Erst Reddit/TikTok testen, dann IG2026-06-17
Konzept zuerst auf Reddit (Conversion / echte Link-Klicks) + TikTok (Scroll-Stop) validieren, Sieger nach ~2-3 Wochen auf IG commiten. Warum: falsch trainierte Audience drosselt spaetere Pivots — frueh testen, solange die Audience klein ist.
Engagement-Bot deaktiviert2026-06-17
Explore-Likes/Follows-Automation aus. Warum: schwachster Reichweiten-Hebel, mindere Signale, Ban-Risiko. Nur manuelles, gezieltes Engagement auf IG.
Riley-Posting kuenftig via Graph API2026-06-17
Automatisiertes Posten ueber offizielle Graph API statt Playwright-Browser-Login. Warum: von Meta sanktioniert, kein "neues Geraet / Takeover"-Signal.
Neuer Riley-IG-Account isoliert am PC2026-06-17
Erstellung in dediziertem Browser-Profil am PC (nicht am privaten Handy), email-only + Prepaid-SIM als Reserve. Warum: IG = strengste Plattform (Geraete-Clustering), Trennung von Merts echter Identitaet.
TikTok-Standalone-Scripts behalten2026-06-17
tiktok_engage.py / tiktok_export_cookies.py / tiktok_cookies.json bleiben (Audit 2026-06-17). Stehen neben dem Backend-Service, sind konzeptionell passend. Kein Fremdprojekt.
whatsapp_video.py + lyrics_video_ui.py gehoeren zu ReelForge2026-05-29
Urspruenglich aus beatfactory kopiert, aber bewusste Architektur-Entscheidung (HANDOVER.md 2026-05-29): Dateien gehoeren jetzt zu reelforge/instapi, werden von server.py + render_engine.py importiert.
Offene Aufgaben für Mert
- Fanvue OAuth abschließen einmalig — Im Fanvue-Account einloggen und die OAuth-Verbindung freigeben, damit der automatische Chat-Bot wieder laufen kann. Ohne das bleibt der Fanvue-Chat dauerhaft pausiert.
- Riley Reddit/TikTok-Test starten einmalig — Beide Konzepte (Self-aware AI Girlfriend + Flugbegleiterin) auf Reddit und TikTok als Test-Posts live schalten. Nach ca. 2–3 Wochen anhand der Ergebnisse entscheiden, welches Konzept auf Instagram weiterläuft.
- Riley Reddit-Account aufwärmen (Warmup) routine — 1–2 Wochen täglich ~10–20 echte Kommentare (kein Copy-Paste) mit dem Riley-Reddit-Account. KARMA/KOMMENTIEREN: r/FreeCompliments (erst andere loben, dann selbst), r/AskReddit, r/CasualConversation, r/aww. SELFIES (harmlos, angezogen, ohne Link): r/amihot, r/Rateme. MITLESEN/LIKEN (spätere Werbe-Subs): r/OnlyFansPromotions, r/OnlyFans101. NOCH KEINE Fanvue-Links! Ziel ~100–300 Karma. Reift Tag 14 (~4. Juli) → dann "Riley ist aufgewärmt" melden, ich schalte den Auto-Poster scharf. Tägliche Erinnerung kommt ohnehin 9:30 per Telegram.
- Riley neuen Instagram-Account anlegen einmalig — Am PC in einem eigenen Browser-Profil einen neuen Instagram-Account für Riley erstellen (mit frischer Email + Prepaid-SIM als Reserve). Danach den Handle ins System eintragen und Graph-API anbinden — erst nach dem Reddit/TikTok-Test und einem kurzen Warmup.
- Manuelles Engagement auf Instagram routine — Einmal pro Woche gezielt echte Kommentare auf größere Accounts in der Nische hinterlassen (kein Bot). Das signalisiert Instagram echte Aktivität und hilft beim Wachstum.
Notizen
Stand Juni 2026: Mila-Pipeline laeuft stabil und automatisch (Prompt → Bild → QC → Post → Lernen). Riley im Relaunch nach IG-Flag — USP-Entscheidung getroffen, Konzept-Test auf Reddit/TikTok steht aus. Fanvue Chat-Bot wartet auf OAuth-Freigabe. Engagement-Bot deaktiviert. Verwandtes Werkzeug: ReelForge (Desktop-App unter scripts/reelforge/) — baut aus Songs + Lyrics vertikale Reels, laeuft auf dem Windows-PC und speist Reels manuell in die instapi-Pipeline ein.
AutoPi⏸ PausiertAutoPi ist Merts persoenliches Gebrauchtwagen-Assistent-System. Es sucht automatisch auf Kleinanzeigen nach guenstigen Autos im Umkreis von 25 km um Zirndorf (PLZ 90522), bewertet jede Anzeige mit KI und schickt eine Telegram-Nachricht, wenn ein echtes Schnaeppchen auftaucht. Mert kauft das Auto, repariert es selbst und verkauft es weiter — das System trackt alle Kosten und Gewinne. AKTUELL PAUSIERT seit 17.06.2026 (Docker-Container gestoppt).
AutoPi ist Merts persoenliches Gebrauchtwagen-Assistent-System. Es sucht automatisch auf Kleinanzeigen nach guenstigen Autos im Umkreis von 25 km um Zirndorf (PLZ 90522), bewertet jede Anzeige mit KI und schickt eine Telegram-Nachricht, wenn ein echtes Schnaeppchen auftaucht. Mert kauft das Auto, repariert es selbst und verkauft es weiter — das System trackt alle Kosten und Gewinne. AKTUELL PAUSIERT seit 17.06.2026 (Docker-Container gestoppt).
Funktionsweise
- Scraping — Kleinanzeigen (curl_cffi gegen Cloudflare), PLZ 90522, 25 km Radius, ~60 Anzeigen pro Scan
- Vergleichswagen — aehnliche Fahrzeuge sammeln → Median-Marktwert berechnen (±3 Jahre / ±80k km)
- Bewertung — Rabatt% und Betrugs-Score (Scam-Score) je Anzeige berechnen
- Schnaeppchen-Filter — ≥15 % Rabatt + Scam-Score <60 → automatisch tief analysieren
- Bild-Analyse — Gemini 2.5 Flash Vision: Tacho-OCR, Unfallspuren, Zustand (bis 5 Fotos)
- Web-Recherche — DuckDuckGo: bekannte Modell-Maengel, Foren, YouTube-Reparaturvideos
- Claude-Verdict — Claude Sonnet fasst alles zusammen → BUY / MAYBE / PASS
- Telegram-Alert — bei BUY oder MAYBE → Nachricht an Mert
- Inventar & P&L — Kauf, Reparaturkosten, Verkauf tracken → Dashboard-Uebersicht
Automatisierungen
Backend (FastAPI)pausiert
Das ist das unsichtbare Herzstück von AutoPi — laeuft als Docker-Container im Hintergrund und stellt alle Funktionen bereit: Scraping, Bewertung, Analyse, Datenbank. Ohne ihn tut sich gar nichts. Wird nicht automatisch gestartet — Mert startet ihn manuell wenn AutoPi gebraucht wird. Aktuell pausiert seit 17.06.2026.
Frontend (React)pausiert
Die Webseite, die Mert im Browser oeffnet. Zeigt alle gefundenen Deals, das Inventar und die Kosten. Hier drueckt Mert auch auf "Full Scan starten". Laeuft als eigener Docker-Container — ebenfalls pausiert seit 17.06.2026, also im Moment nicht erreichbar.
Full-Scanmanuell / pausiert
Der eigentliche Such-Durchlauf: Mert drueckt einmal einen Button im Browser, dann laedt AutoPi selbststaendig ~60 Kleinanzeigen, berechnet fuer jedes Auto den Marktwert und filtert die Schnaeeppchen heraus. Das dauert je nach Trefferzahl ein paar Minuten. Wird ausschliesslich manuell ausgeloest — kein automatischer Timer. Letzter Scan: Anfang Mai 2026. Aktuell ruhend (Container gestoppt).
Deep-Analysis-Loopasync / pausiert
Laeuft automatisch im Hintergrund, waehrend der Full-Scan noch laeuft. Fuer jeden Treffer, der guenstig genug und unverdaechtig genug ist (mind. 15 % unter Marktwert, niedriger Betrugs-Score), schaut AutoPi tiefer hin: Fotos analysieren, Probleme im Internet nachschlagen, dann ein klares Urteil (Kaufen / Vielleicht / Weiter) per KI erstellen und bei BUY/MAYBE eine Telegram-Nachricht schicken. Dauert insgesamt 30–60 Minuten. Aktuell ruhend.
Daten & Datenbank
autopi.db
Alle Scrape-Ergebnisse, Vergleichswagen, KI-Analysen, Inventar und Kosten an einem Ort. Live-Zahlen (Anzahl Listings, Bestand) zieht der Canvas direkt aus der DB.
listingscomparablesanalysesinventorycostsworkshop_assetsscanssearchesseen_urls
Produktions-Pipeline
1 · Kleinanzeigen scrapen~60 Anzeigen
Backend laedt ~60 Anzeigen (3 Seiten), ueberwindet Cloudflare-Schutz durch Browser-Imitation (curl_cffi). Rate-Limiting: 8–15 s Pause zwischen Requests.
2 · Vergleichswagen sammelnMarktwert
Fuer jedes gefundene Auto werden aehnliche Fahrzeuge auf Kleinanzeigen gesucht (gleiche Marke/Modell, ±3 Jahre, ±80k km) → Median-Marktwert berechnen.
3 · Bewertung & Filter≥15 % / Scam <60
Rabatt% und Betrugs-Score je Anzeige. Nur wer ≥15 % unter Marktwert liegt UND Scam-Score unter 60 hat, kommt in die Tiefenanalyse.
4 · Bild-Analyse (Gemini)Gemini Vision
Bis zu 5 Fotos der Anzeige werden per Gemini 2.5 Flash ausgewertet: Tacho-Kilometerstand, Unfallspuren, Innen- und Aussenzustand, Reifenzustand.
5 · Web-RechercheDuckDuckGo
DuckDuckGo-Suche nach bekannten Problemen des Modells (Forum-Posts, ADAC, YouTube-Reparaturvideos). Gesperrte Domains mit Timeout werden uebersprungen.
6 · Claude-VerdictBUY / MAYBE / PASS
Claude Sonnet fasst Marktwert, Bilder und Recherche zusammen und gibt ein klares Urteil: BUY (kaufen), MAYBE (nochmal hinschauen) oder PASS (ueberspringen).
7 · Telegram-AlertTelegram
Bei BUY oder MAYBE bekommt Mert sofort eine Telegram-Nachricht mit Link zur Anzeige, Verdict und Begruendung. Dann Deals-Seite im Browser checken.
Daten & Quellen
Kleinanzeigen
Live-Gebrauchtwagen-Anzeigen (Scraping, kein offizielles API)
DuckDuckGo
Webrecherche zu Modell-Maengeln (Forum-Posts, ADAC, gutefrage)
YouTube
Reparaturvideos zu Modellen und Problemen
Gemini 2.5 Flash
Bildanalyse (Tacho-OCR, Schaden, Zustand) — Google Free Tier
Claude Sonnet
Kauf-Verdict und Zusammenfassung (on-demand, eigener API-Key)
Telegram Bot API
Deal-Alerts an Mert (kostenlos)
Wer/was arbeitet
Backend (FastAPI)
Scrapt, bewertet und analysiert — REST-API auf Port 8100
Claude Sonnet
Tiefenanalyse → BUY / MAYBE / PASS Verdict
Gemini Vision
Bildanalyse (Fotos der Anzeige)
Telegram-Bot
Deal-Alerts an Mert
React-Frontend
Browser-Oberflaeche (Port 8180) — Scan starten, Deals sehen, Inventar verwalten
Technik
BackendPython 3.11 · FastAPI · Pydantic
FrontendReact 18 · Vite 5 · Custom CSS (kein UI-Framework)
Container{'Docker Compose (2 Container': 'autopi-backend + autopi-frontend)'}
DBSQLite WAL · autopi.db unter /home/pi/autopi/data/db/
Scrapingcurl_cffi (chrome110-TLS-Imitation gegen Cloudflare)
KIClaude Sonnet (Verdict) · Gemini 2.5 Flash (Bildanalyse)
InfrastrukturRaspberry Pi 5 · Tailscale (100.92.115.43) · System-Nginx als Gateway
Roadmap — AutoPi
Fertig — Kernsystem
Kleinanzeigen-Scraperfertig
curl_cffi mit Chrome110-TLS, Detail-Seiten-Parsing aus eingebettetem JSON, 3 Seiten, Retry bei Rate-Limiting.
Vergleichswagen & Marktwertfertig
Comparables-System fuer ~270 Fahrzeuge in DB; Median-Marktwert mit Toleranzen (±3 J, ±80k km).
Bewertungs-Enginefertig
Rabatt% und Betrugs-Score (0–100) je Listing. Schwellen konfigurierbar (15 % / 60).
Deep-Analysis-Pipelinefertig
Gemini Vision + DuckDuckGo-Recherche + Claude Sonnet Verdict end-to-end.
Telegram-Alertsfertig
BUY/MAYBE → Nachricht an Mert mit Link und Begruendung.
Inventar + Kosten + P&Lfertig
Kauf/Reparatur/Verkauf tracken; Kosten-Typen (Fahrzeug, Verbrauch, Werkstatt); Dashboard-Uebersicht.
React-Frontendfertig
Alle Screens deployed: Scan, Deals, Listings, Inventar, Workshop, Dashboard.
Docker-Deploymentfertig
2 Container (backend :8100, frontend :8180) hinter System-Nginx-Gateway.
Offen — nach Reaktivierung
Audi A4 verkaufen + P&L abschliessenMert
Das Auto im Bestand inserieren, nach Verkauf Preis + Verkaufs-km im System eintragen, damit P&L stimmt.
Full Scan startenwenn benoetigt
System ist seit ~5 Wochen idle. Wenn Mert wieder nach Schnaeppchen sucht: im Frontend 'Full Scan starten' druecken, dann Deals-Seite pruefen.
Nice-to-have
Eigener Telegram-Botgeplant
Aktuell wird PokePis Bot-Token mitbenutzt. Eigener Bot waere sauberer.
Git Remote einrichtengeplant
Kein Push-Ziel konfiguriert — Backup-Moeglichkeit fehlt.
DB-Backup-Scriptgeplant
autopi.db hat noch kein automatisches Backup-Script.
Gateway + terminal-auth auslagernInfrastruktur
Beide Ordner liegen unter /home/pi/autopi/, gehoeren aber zur Pi-Infrastruktur (nicht zu AutoPi). Sollten nach /home/pi/gateway/ bzw. /home/pi/terminal-auth/ verschoben werden.
Entscheidungs-Log
System pausiert (17.06.2026)2026-06-17
Mert hat AutoPi bewusst pausiert — Docker-Container gestoppt (restart=no). Kein aktiver Scan-Betrieb. Reaktivierung: 'docker start autopi-backend autopi-frontend', paused-Flag im Manifest entfernen.
Manifest komplett neu geschrieben2026-06-17
Canvas-Dossier (Abschnitt B aus cleanup_audit/autopi.md) als Grundlage — alle Views (pipeline, dbs, roadmap, decisions) neu und vollstaendig befuellt.
Deep-Analysis ist 2-stufig2026-05-05
Stufe 1 (kostenlos, Comparables-Scoring) laeuft automatisch. Stufe 2 (Claude + Gemini + Web) wird on-demand per Button ODER automatisch bei ≥15 % Rabatt + Scam <60 ausgeloest.
Kein automatischer Cron-Job2026-05-05
Mert startet Scans manuell wenn er suchen will. Kein Timer — so entstehen keine API-Kosten wenn AutoPi gerade nicht benoetigt wird.
Nur Materialkosten (keine Arbeitskosten)2026-05-05
Mert repariert selbst → Arbeitskosten werden nicht erfasst. cost_type: fahrzeug / verbrauch / werkstatt.
Claude Model explizit fixiert2026-05-05
claude-sonnet-4-6 (nicht claude-sonnet-4-20250514). Wichtig fuer Reproduzierbarkeit der Verdicts.
Kleinanzeigen ignoriert vehicleMake/vehicleModel-Parameter2026-05-05
URL-Parameter werden von Kleinanzeigen still ignoriert — nur Keyword-Suche in der URL funktioniert zuverlassig. Scrapt /s-{keyword}/k0c216.
Gateway und terminal-auth fehlplatziert2026-06-17
Beide Ordner liegen unter /home/pi/autopi/, sind aber Pi-weite Infrastruktur (nicht AutoPi-spezifisch). Verschieben ist safe, aber nicht dringend.
Offene Aufgaben für Mert
- Audi A4 verkaufen einmalig — Das Auto im Bestand (Audi A4, Einkauf 525 €) inserieren und verkaufen. Verkaufspreis + Verkaufs-km im System eintragen, damit P&L stimmt.
- Full Scan starten und Deals prüfen einmalig — System ist seit ~5 Wochen idle. Wenn Mert wieder nach Schnäppchen suchen will, im Frontend auf "Full Scan starten" drücken und danach die Deals-Seite durchschauen.
- Telegram-Alerts auf neue Deals prüfen routine — Wenn das System läuft und eine BUY/MAYBE-Meldung per Telegram kommt, die Anzeige auf Kleinanzeigen ansehen und entscheiden ob das Auto gekauft wird.
Notizen
PAUSIERT seit 2026-06-17 (vorher ruhend seit Anfang Mai). Docker-Container (autopi-backend, autopi-frontend) gestoppt mit restart=no. Reaktivieren: "docker start autopi-backend autopi-frontend" im Terminal, dann paused-Flag in diesem Manifest entfernen, dann Full-Scan starten → Tiefenanalysen laufen async (~30–60 Min) → Telegram-Alerts. 1 Auto im Bestand (Audi A4, Einkauf 525 EUR) — noch nicht verkauft, P&L noch offen.
Publishing1
BookPi🟢 läuftVollautomatische eBook-Fabrik fuer Amazon KDP. Das System waehlt selbst eine Nische, schreibt mit Claude ein komplettes Non-Fiction-Manuskript (~22.000 Woerter, 8 Kapitel), prueft jedes Kapitel per Qualitaets-Gate, formatiert EPUB + Paperback-PDF + Cover und liefert Mert ein fertiges Upload-Paket. Ziel ist 500 EUR/Monat passives Einkommen; Mert laedt nur das Paket manuell bei Amazon hoch.
Vollautomatische eBook-Fabrik fuer Amazon KDP. Das System waehlt selbst eine Nische, schreibt mit Claude ein komplettes Non-Fiction-Manuskript (~22.000 Woerter, 8 Kapitel), prueft jedes Kapitel per Qualitaets-Gate, formatiert EPUB + Paperback-PDF + Cover und liefert Mert ein fertiges Upload-Paket. Ziel ist 500 EUR/Monat passives Einkommen; Mert laedt nur das Paket manuell bei Amazon hoch.
Funktionsweise
- Nischen-Wahl — 6 Kandidaten brainstormen + gegen Amazon-Marktdaten validieren → Score → beste Idee gewinnt
- Outline — Claude generiert Titel, Untertitel, Inhaltsverzeichnis (8 Kapitel), Keywords, Kurzbeschreibung
- Kapitel schreiben — Kapitel fuer Kapitel mit Claude Sonnet, direkt danach Inline-Qualitaets-Check
- Quality-Gate — {'Score < 7,0/10 → Kapitel automatisch ueberarbeiten (6 Dimensionen': 'Hook, Lesbarkeit, Struktur …)'}
- Reader-Magnet — Kostenloses Companion-Toolkit (z. B. Checkliste) als E-Mail-Funnel ans Buchende haengen
- Formatierung — {'EPUB (Premium-Typo': 'Lora + Playfair Display) + Paperback-PDF + Cover (1600x2560 px)'}
- Paketierung — 7 A10-Keywords, Kategorie-Empfehlung, Amazon-Beschreibung (HTML), Upload-Schritt-fuer-Schritt
- KDP-Upload — Mert laedt das Paket manuell auf kdp.amazon.com hoch
- Verkäufe tracken — KDP-Report (XLSX) importieren → sales-Tabelle → Nischen-Lernen
Automatisierungen
weekly_book — woechentliches BuchNICHT aktiv — kein Cron eingerichtet
Sucht sich automatisch die beste Nische aus (vergleicht Nachfrage, Konkurrenz und was bisher gut verkauft hat), schreibt dann daraus ein komplettes Buch (Outline, 8 Kapitel, Reader-Magnet, Cover, Metadaten) und legt das fertige Upload-Paket in output/packages/ ab. Mert muss danach nur noch manuell bei Amazon hochladen. ACHTUNG: Das Script ist fertig, aber der automatische Wochenplan ist noch NICHT eingerichtet — kein Crontab-Eintrag. Muss noch aktiviert werden (Sonntags 03:00 Uhr).
generate_book — Buch auf Befehlmanuell / bereit
Erzeugt ein komplettes Buch fuer eine vorgegebene Nische. Ablauf: Titel und Kapitelplan erstellen, jeden Abschnitt schreiben und direkt danach per Qualitaets-Check pruefen (Mindestpunktzahl 7,0/10 — sonst automatisch ueberarbeiten), EPUB + Paperback-PDF + Cover bauen, alle KDP-Metadaten (Keywords, Beschreibung, Kategorien) vorbereiten und alles als fertiges Paket ablegen. Laeuft manuell auf Abruf.
repackage_book — Buch neu verpackenad-hoc / bereit
Baut das EPUB eines bereits gespeicherten Buches komplett neu, OHNE den Inhalt nochmal zu generieren. Nuetzlich wenn sich die Formatierung verbessert hat (z. B. bessere Typo, Reader-Magnet ergaenzt, Cover-Einbettung). So koennen bereits fertige Buecher auf den neuesten Stand gebracht und nochmal bei KDP hochgeladen werden. Laeuft manuell auf Abruf.
import_kdp_sales — Verkaufsdaten einlesenmanuell / noch kein Report
Liest die monatlichen Verkaufsberichte von Amazon KDP ein (XLSX-Datei, die Mert manuell exportiert und in den Ordner data/kdp_reports/ legt) und speichert die Zahlen in der Datenbank. Das System nutzt diese Daten dann beim naechsten Buch, um bessere Nischen zu waehlen. Noch kein Report importiert — erst sinnvoll wenn erste Verkäufe da sind.
Daten & Datenbank
bookpi.db
Vollstaendige Projekt-Datenbank. Sales-Tabelle ist bereit, aber noch leer (noch kein KDP-Report importiert). generation_learnings sind alle angewendet.
bookschaptersquality_reviewsgeneration_learningsniche_scoreskeyword_researchsales
Produktions-Pipeline
1 · Nischen-Researchniche_picker
Brainstormt 6 konkrete Buchideen und prueft sie gegen echte Amazon-Suchdaten (Nachfrage, Konkurrenz). Beste Idee gewinnt (Markt-Score + Performance-Bonus aus frueheren Buechern).
2 · OutlineSonnet
Claude erstellt hyper-spezifischen Titel, Untertitel, Inhaltsverzeichnis (8 Kapitel), 7 Keywords und Amazon-Kurzbeschreibung.
3 · Kapitel-GenerierungQuality-Gate
Kapitel fuer Kapitel schreiben; direkt danach Inline-Review (6 Dimensionen). Score < 7,0 → automatische Ueberarbeitung.
4 · Reader-MagnetE-Mail-Liste
Kostenloses Companion-Toolkit (Checkliste, Vorlagen) wird generiert und ans Buchende gehaengt — Einstieg in den E-Mail-Funnel.
5 · Formatierungebooklib · reportlab
EPUB mit Premium-Typo (Lora + Playfair Display, Callout-Boxen) + Paperback-PDF (Gutenberg-Rahmen) + nischen-spezifisches Cover (1600x2560 px).
6 · Metadaten & PaketPackage
7 A10-Keywords, 3-Kategorie-Strategie, Amazon-Beschreibung als HTML, Schritt-fuer-Schritt Upload-Anleitung — alles in output/packages/ abgelegt.
7 · Upload & Verkäufeimport_kdp_sales
Mert laedt das Paket manuell bei Amazon hoch. Danach monatlich KDP-Report importieren → Nischen-Loop.
Daten & Quellen
Claude Sonnet 4.6
Outline, Kapitel, Reader-Magnet, Keywords, Learnings (Key von investpi als Fallback)
Bright Data Web Unlocker
Amazon-Seiten scrapen fuer Marktvalidierung (Nachfrage + Konkurrenz); Zone "bookpi"
Amazon KDP
Veroeffentlichung + Verkaufsdaten (XLSX-Export durch Mert)
settings.yaml
Nische, Qualitaets-Bar (7,0/10), Preis (6,99 $), Kategorien
Wer/was arbeitet
Claude Sonnet 4.6
Buch-Generierung end-to-end (Outline, Kapitel, Reader-Magnet, Metadata)
Niche-Picker
Multi-Kandidaten-Brainstorming + Marktvalidierung → Score
Quality-Gate
Inline-Scoring (6 Dimensionen) + automatische Revision bei Score < 7,0
Sales-Import
Toleranter KDP-Export-Parser (XLSX/CSV → sales-Tabelle)
Technik
SprachePython 3.13 (nativ, kein Docker)
LLMClaude Sonnet 4.6 (Anthropic SDK); Haiku als Kosten-Fallback geplant
eBookebooklib (EPUB) + reportlab (Paperback-PDF) + Pillow (Cover)
TypoLora + Playfair Display + Gold-Akzent (eingebettete Fonts im EPUB)
DatenbankSQLite (bookpi.db) — alle Buch/Kapitel/Review/Sales/Learnings-Daten
MarktdatenBright Data Web Unlocker (Token + Zone in .env)
Qualitaets-Bar7,0/10 (Inline-Gate; automatische Revision bei Unterschreitung)
Ziel-Umfang~22.000 Woerter (8 Kapitel)
VersionskontrolleGit (lokaler main-Branch, kein GitHub-Remote)
Roadmap — BookPi
Fertig
Projekt-Fundamentfertig
/home/pi/book-pi, Python 3.13, SQLite, .env, requirements.txt, Git (lokal)
Nischen-Research-Enginefertig
niche_picker.py + amazon_market.py — Bright Data scrapt Amazon, Score berechnen
Buch-Generator mit Quality-Gatefertig
outline.py + generator — Kapitel schreiben, Inline-Review, Auto-Revision bei < 7,0
Formatierung (EPUB + PDF + Cover)fertig
ebooklib EPUB mit eingebetteten Fonts, reportlab PDF, Pillow Cover (1600x2560)
Reader-Magnet / E-Mail-Funnel-Materialfertig
Companion-Toolkit generiert, Paket in output/funnel/book1/ bereit
Paketierung & Metadatenfertig
A10-Keywords, HTML-Beschreibung, Kategorie-Strategie, Upload-Anleitung je Buch
Self-Learning-Loopfertig
311 Learnings aus 70 Quality-Reviews extrahiert und in alle Folge-Buecher injiziert
Sales-Import-Scriptfereit
import_kdp_sales.py — KDP-XLSX/CSV → sales-Tabelle; bereit fuer ersten Report
Laeuft / Haengt an Mert
4 fertige Buecher bei KDP hochladenMert
Pakete liegen in output/packages/. Mert muss jeden Upload-Assistenten oeffnen und Buch manuell einstellen (KI-Checkbox + Preis 6,99 $).
Woechentlicher Cron NICHT aktivfehlt
weekly_book.py ist fertig, aber der Cron-Eintrag fehlt noch in crontab. Muss noch eingetragen werden (0 3 * * 0 …).
Geplant
E-Mail-Funnel live schaltengeplant
MailerLite-Konto anlegen, Anmeldeseite einrichten. Anleitung in output/funnel/book1/README_DEPLOY.md
KDP-Sales-Reports monatlich importierengeplant
Sobald erste Verkäufe da sind — XLSX exportieren, in data/kdp_reports/ legen, import_kdp_sales ausfuehren.
Author Central einrichtengeplant
authorcentral.amazon.com — A+-Content und Autorenprofilseite
GitHub-Remote anlegenoptional
Aktuell nur lokales Git — gh CLI oder Token benoetigt fuer Remote-Backup
Entscheidungs-Log
KORREKTUR: weekly_book-Cron war faelschlich als aktiv markiert2026-06-17
2026-06-17: Audit ergab, dass kein crontab-Eintrag existiert. Der woechtliche Cron laeuft NICHT. Manifest-Status auf problem korrigiert. Muss noch eingetragen werden.
Generierungskosten 0,03–0,58 EUR/Buch2026-06-17
Buch 1–4 sehr guenstig (Claude effizient); Buch 5 teurer wegen laengerer Kapitel. Gesamtkosten bisher ca. 0,71 EUR fuer 5 Buecher.
Quality-Bar bei 7,0/10Design
Schwelle fuer automatische Ueberarbeitung. Darunter kein Kapitel ohne Revision. Ø-Score aller 70 Reviews liegt bei 8,40 (Bandbreite 7,7–8,8).
Nur manueller KDP-UploadDesign
Amazons Upload-API ist nicht oeffentlich. Mert laedt manuell hoch — Anleitung liegt im Paket. KI-Content-Checkbox muss angekreuzt werden (Pflicht seit 2024).
Preis 6,99 $ (70 % Royalty)Config
Im KDP-Fenster 2,99–9,99 USD gilt 70 % Royalty-Rate. 6,99 $ ist der Ziel-Preis fuer Non-Fiction in diesen Nischen.
Reader-Magnet als E-Mail-Funnel-EinstiegDesign
Jedes Buch bekommt ein kostenloses Companion-Toolkit. Leser tragen sich ein → MailerLite-Liste → Folgebuecher vermarkten. MailerLite noch nicht eingerichtet.
Claude API-Key von investpi als FallbackConfig
bookpi nutzt den Anthropic-Key aus /home/investpi/invest-pi/.env als Fallback, falls eigener Key fehlt.
Offene Aufgaben für Mert
- Fertige Bücher bei KDP hochladen einmalig — 4 fertige Buecher liegen bereit (output/packages/). Mert muss jeden Upload-Assistenten oeffnen, das Paket nehmen und das Buch manuell bei Amazon KDP einstellen — inklusive KI-Content-Checkbox und Preis (6,99 $).
- KDP-Verkaufsbericht importieren routine — Im KDP-Dashboard den monatlichen Verkaufsbericht als XLSX exportieren und dann auf dem Pi mit dem Job import_kdp_sales einlesen, damit das System daraus lernt.
Notizen
Stand Juni 2026: 5 Buecher generiert (Nischen ai_automation x3, productivity, health), 1 veroeffentlicht ("The One-Person AI Business Machine"), 4 Pakete liegen bereit zum Upload in output/packages/. Ø-Qualitaet 8,40/10. Self-Learning-Loop laeuft (311 Learnings, alle angewendet). WICHTIG: woechentlicher Cron ist NICHT aktiv — muss noch in crontab eingetragen werden. MailerLite-Funnel-Materialien fertig, aber noch nicht live geschaltet. Mert muss die 4 Pakete hochladen und optional den Cron aktivieren.
Creator-Tooling1
BeatFactory🟢 läuftBeatFactory ist eine vollautomatische KI-Musik-Fabrik auf dem Raspberry Pi: Sie erfindet Trap-Beats (Suno AI), prueft ihre Qualitaet per Gemini-KI, baut ein animiertes YouTube-Video (FLUX-Bild + Wan-Animation + FFmpeg) und laedt alles selbst hoch — täglich, ohne dass Mert etwas anruehren muss. YouTube-Kanal: @VelvetBeats.
BeatFactory ist eine vollautomatische KI-Musik-Fabrik auf dem Raspberry Pi: Sie erfindet Trap-Beats (Suno AI), prueft ihre Qualitaet per Gemini-KI, baut ein animiertes YouTube-Video (FLUX-Bild + Wan-Animation + FFmpeg) und laedt alles selbst hoch — täglich, ohne dass Mert etwas anruehren muss. YouTube-Kanal: @VelvetBeats.
Funktionsweise
- Style-Wuerfel — Mood / Kuenstler / BPM / Tonart zufaellig aus 6 Stimmungen und 17 Kuenstler-Profilen
- Beat-Generierung — Suno V5.5 generiert instrumentalen Beat per API (Task-basiert, Poll bis fertig)
- QC-Schleife — Gemini benotet BEIDE Suno-Clips (Score 1-10), besserer gewinnt; unter 7,0 → neuer Versuch, max 3×
- Mastering — Matchering mastert auf Profi-Referenztrack (Frequenz/Lautheit/Stereo, ~-12 LUFS) + Producer-Tag; Fallback loudnorm -14
- Hintergrundbild — FAL FLUX generiert passendes 1920×1080 Bild je Stimmung (z.B. Neon-Stadt fuer "dark")
- Loop-Animation — fal Wan 2.2 i2v belebt das Bild zu ~5s Clip; Ping-Pong-Loop (vor+rueckwaerts) laeuft endlos
- Video-Bau — FFmpeg: Endlos-Loop + Beat-Titel-Text + komplette Audio → 16:9 Full + 2× 9:16 Shorts (30s, Ausschnitte 10s & 45s)
- YouTube-Upload — Video + Short + Thumbnail per YouTube Data API; Telegram-Ping an Mert mit Links
- Verlaufs-Log — history.json rollierend (letzte 90 Beats mit Name, Mood, BPM, YouTube-ID)
Automatisierungen
Haupt-Lauf · Beat-Pipeline (Di/Do/Sa 20:03)Di/Do/Sa 20:03 Uhr
Der Pi startet dreimal pro Woche abends automatisch die ganze Fabrik. Zuerst wuerfelt das System Stimmung, Tonart, BPM und einen Kuenstler-Stil. Dann bestellt es bei Suno AI einen instrumentalen Beat und wartet, bis er fertig ist. Gemini hoert rein und gibt eine Note — liegt sie unter 6,5, wird ein verbesserter Beat bestellt (bis zu 3 Versuche, der beste gewinnt). Danach wird der Beat gemastert (Lautstaerke auf Streaming-Standard) und ein passendes Hintergrundbild per FLUX gemalt. Wan 2.2 belebt das Bild zu einem kurzen Videoclip, der per Ping-Pong- Technik endlos laeuft. FFmpeg baut daraus das fertige YouTube-Video (16:9) und einen 30-Sekunden-Short (9:16). Beides ladet das System selbst hoch, setzt das Thumbnail und schickt Mert per Telegram den fertigen Link. Alles zusammen dauert ca. 15–30 Minuten.
Thermal-Guard (automatisch innerhalb jedes Laufs)vor jedem Render-Schritt
Vor jedem rechenintensiven Schritt (Mastering, Animation, Video-Bau) misst die Pipeline die Temperatur des Raspberry Pi. Ist er heisser als 72 Grad, wartet sie — bis zu 10 Minuten — bis er sich auf unter 60 Grad abgekuehlt hat. So laeuft der Pi nie heiss leer und der Lauf bricht nicht durch Ueberhitzung ab.
QC-Retry-Loop (automatisch innerhalb jedes Laufs)intern, max. 3 Versuche
Direkt nach der Beat-Generierung bewertet Gemini den Beat auf einer Skala von 1–10. Landet er unter 6,5 Punkten, schickt das System einen verbesserten Prompt an Suno und generiert einen neuen Versuch. Das passiert bis zu zwei Mal; am Ende gewinnt immer der beste Versuch — auch wenn keiner die Mindestnote erreicht hat.
Daten & Datenbank
history.json
Rollierendes Log der letzten 90 hochgeladenen Beats: Name, Stimmung, BPM, Tonart, YouTube-Video-ID. Wird nach jedem erfolgreichen Upload ergaenzt; aelteste Eintraege fallen automatisch heraus.
output/DATUM_UHRZEIT/
Pro Produktions-Lauf ein Unterordner (z.B. output/20260616_2003/). Enthaelt: raw-MP3, gemastertes MP3, Hintergrundbild (PNG), Thumbnail (JPG), Full-Video (MP4), Short (MP4). Ca. 50-80 MB je Lauf.
reference_analysis.json
Stil-Profil der beiden Referenz-Tracks (Pajel, Mero) — wird von analyze_references.py erstellt und als Kontext fuer den Gemini-Prompt genutzt.
playlists.json
Cache der YouTube-Playlist-IDs je Mood (smooth/bouncy/dark/...). Jeder neue Upload wird automatisch in die passende Mood-Playlist einsortiert; existiert sie noch nicht, wird sie SEO-benannt angelegt. Mehr Wiedergabezeit + rankbare Playlist-Seiten.
Produktions-Pipeline
1 · Style-WuerfelZufall + Profil
Das System wuerfelt Stimmung (smooth / bouncy / dark / summer / chill / wavy), Tonart, BPM und einen Referenz-Kuenstler (z.B. "Yeat x Cochise Type Beat"). 17 Kuenstler-Profile mit je 2 Referenz-Fotos fuer Thumbnails.
2 · Beat-Generierung (Suno V5.5)KI-Musik
Suno AI generiert den instrumentalen Beat per API. Das Skript schickt den Prompt ab und pollt solange, bis der Beat fertig gerendert ist.
3 · Qualitaets-Check (Gemini)QC-Loop
Gemini "hoert" BEIDE von Suno gelieferten Clips und benotet sie (1-10). Der bessere gewinnt. Unter 7,0 Punkte → neuer Versuch mit verbessertem Prompt. Bis zu 3 Versuche.
4 · Mastering (Matchering)Profi-Referenz
Producer-Tag "Velvet Beats" wird eingeblendet. Das Mastering laeuft ueber Matchering: der Beat wird auf das Klangprofil eines Profi-Referenztracks angeglichen (Frequenzbalance, Lautheit, Stereobreite, Limiter) → konkurrenzfaehige ~-12 LUFS. Faellt bei Fehler auf klassisches loudnorm-Mastering zurueck.
5 · Hintergrundbild + AnimationPing-Pong-Loop
FAL FLUX malt ein 1920×1080 Bild zur Stimmung (z.B. neon-beleuchtete Stadt fuer "dark"). Wan 2.2 belebt es zu einem ~5-Sekunden-Clip. Ping-Pong-Technik (vor+rueckwaerts) ergibt einen nahtlosen Endlos-Loop. Fallback: Standbild.
6 · Video-Bau (FFmpeg)Full + Short
FFmpeg legt den Endlos-Loop unter die gesamte Beat-Laenge, brennt den Beat-Titel als Text ein und ergibt das fertige 16:9-YouTube-Video. Parallel dazu: 9:16-Short (30 Sekunden) fuer mehr Reichweite.
7 · Upload + BenachrichtigungYouTube + Telegram
Video, Short und Custom-Thumbnail gehen per YouTube Data API live. Direkt danach schickt ein Telegram-Bot die Video-Links an Mert.
Daten & Quellen
Suno-API
Beat-Generierung, Modell V5.5, Task-basiert (sunoapi.org)
Gemini 3.5-flash
Audio-QC (Score, Schwaechenprofil, verbesserter Prompt)
fal.ai / FLUX
Hintergrundbild-Generierung (1920×1080 PNG)
fal.ai / Wan 2.2
Bild-zu-Video-Animation (~$0.40 pro Beat)
YouTube Data API
Upload Video/Short, Custom-Thumbnail, Channel-Verwaltung
Telegram Bot API
Status-Benachrichtigung + Video-Links an Mert nach jedem Upload
BASE_STYLES / artists/
6 Stimmungen (smooth/bouncy/dark/summer/chill/wavy) + 17 Kuenstler-Referenz-Ordner
references/
{'2 Referenz-Beats (Pajel, Mero)': 'Stil-Analyse (Gemini) UND Master-Referenz fuer Matchering'}
Matchering
{'Lokales Open-Source-Mastering': 'matcht Beat auf Referenz (Frequenz/Lautheit/Stereo + Limiter), ~53s/Beat'}
Wer/was arbeitet
Beat-Generator (Suno)
generiert und pollt den instrumentalen Beat per KI
Gemini-Analyzer
bewertet Audio, erkennt Key/BPM, verbessert den Prompt fuer den naechsten Versuch
FLUX-Maler
generiert stimmungsgenaues Hintergrundbild per KI
FFmpeg-Renderer
baut Video + Short (Regel-basiert, thermal-bewusst, 2 Threads)
YouTube-Uploader
laedt Video/Short/Thumbnail hoch, verwaltet den Kanal
Thermal-Guard
misst Pi-Temperatur vor jedem schweren Schritt; wartet bei >72°C bis <60°C
Technik
SprachePython 3.13 (nativ, kein Docker)
Audio-GenerierungSuno-API V5.5 (Task-basiert)
Audio-QCGemini 3.5-flash (google-genai)
Visualsfal_client (FLUX + Wan 2.2) · PIL/Pillow · numpy
Video-BauFFmpeg (Loop, Text-Overlay, LUFS-Normalisierung)
Uploadgoogle-api-python-client (YouTube Data API)
SchedulingCron (kein systemd, kein Docker)
Thermalthermal_zone0 Polling direkt in beat_generator.py
Verlaufhistory.json (JSON, rollierend 90 Eintraege)
Pfad/home/pi/beatfactory · User pi
Roadmap — BeatFactory / Velvet Beats
Fertig — Pipeline produktiv
Beat-Pipeline komplettlive
Suno → QC → Mastering → FLUX → Wan → FFmpeg → YouTube vollautomatisch. Laeuft seit Ende Mai 2026.
Animierter Loop-Hintergrundfertig
Wan 2.2 i2v + Ping-Pong-Technik: nahtloser Endlos-Loop, kein sichtbarer Schnitt.
YouTube Short (9:16)fertig
Parallel zum Haupt-Video wird automatisch ein 30-Sekunden-Short generiert und hochgeladen.
Telegram-Benachrichtigungfertig
Mert bekommt nach jedem Upload automatisch eine Nachricht mit dem Video-Link.
Thermal-Guardfertig
Pi prueft seine Temperatur vor jedem Render-Schritt. Ueber 72°C: Pause bis unter 60°C.
Fallback-Kettefertig
FLUX failt → bg_westside-Standbild; Wan failt → Standbild; Mastering failt → Raw-Beat. Pipeline bricht nie.
Laeuft — aktuelle Probleme
Suno-DNS/Timeout-Fehler haertenoffen
5 Laeufe zwischen 2.-13.06 schlugen fehl (leere Output-Ordner). Ursache: Suno-API intermittierend nicht erreichbar. Retry/Backoff um den API-Call wuerde das loesen.
Geplant — naechste Schritte
Shorts-Crossposting TikTok + Instagram ReelsMert-Aufgabe
Groesster verbleibender Reichweite-Hebel: die fertigen Shorts automatisch auch auf TikTok & IG Reels posten. Wartet auf Konto-Zugaenge von Mert (instapi-Projekt als Basis vorhanden).
BeatStars-Store einrichtenMert-Aufgabe
BeatStars-Account anlegen, Store aufsetzen, Link als BEATSTARS_URL in .env → erscheint dann automatisch in Beat-Titeln und -Beschreibungen auf YouTube.
Reichweite — laufende Beobachtungbeobachten
Hebel umgesetzt (täglich, Rising-Artists, 2 Shorts/Beat). Offen + bei Mert: Kanal in "Velvet Beats" umbenennen. In 2-4 Wochen Views erneut prüfen — wenn die Rising-Artists ranken, dort weiter verdichten; sonst Artist-Pool nachjustieren.
Entscheidungs-Log
Thumbnail-Qualität gehärtet (nie mehr verpixelte Mini-Künstler)2026-06-21
21.06., Reaktion auf schlechtes "Candy"-Thumbnail (winziger, verpixelter Künstler). Vier Fixes: (1) höchstauflösendes Foto je Künstler statt zufällig; (2) nach dem Freistellen auf das Subjekt zuschneiden → füllt immer die Höhe (kein Schweben mehr); (3) Qualitäts-Gate: zu kleines/schlecht freigestelltes Subjekt (<500px) → der zweite Künstler wird probiert, sonst sauberes Text-auf-FLUX-Bild-Thumbnail; (4) Titel-Text größer (175/200 statt 140/160) mit Auto-Shrink, damit lange Namen nicht überlaufen. Ergebnis: entweder scharfer Künstler-Ausschnitt oder cleanes Text-Thumbnail — nie Murks. Live-Thumbnail von "Candy" nachträglich ersetzt.
Monatliche Kosten (Stand 06/2026, täglicher Upload ≈ 30 Beats/Monat)2026-06-19
ALLES nutzungsabhängig (Pay-per-use, KEIN Abo). Pro Beat: fal Wan-2.2-Animation $0,08/s × ~5s = ~$0,40 (mit Abstand größter Posten), Suno ~8-10 Credits/Beat ≈ ~$0,06-0,10 (× Ø-Versuche der QC-Schleife, Retry kostet je einen weiteren Suno-Call!), FLUX-Bild ~$0,01, Gemini QC+Prompt ~$0,02. → ~$0,50-0,55/Beat × 30 ≈ $15-17/Mon + Pi-Strom ~$1. GESAMT ≈ $16-19/Mon (~15-18 €). Matchering-Mastering, 2. Short, YouTube/Telegram = $0 (lokal bzw. gratis). Suno-Guthaben am 19.06.: 690 Credits ≈ ~70 Beats. Größter Hebel = Wan (auf 580p drosselbar: ~$0,30 statt $0,40). Exakter Credit→€-Kurs noch von Mert zu bestätigen.
Beat-Erzeugung auf Optimum — neuer Workflow2026-06-19
19.06., Kern-Upgrade der Audio-Qualität: (1) BEIDE Suno-Clips pro Generierung werden per Gemini bewertet, der bessere gewinnt (Suno liefert immer 2 — vorher wurde einer verworfen → gratis Qualitätsgewinn). (2) QC-Hürde 6,5 → 7,0. (3) Mastering komplett neu: statt simplem loudnorm jetzt MATCHERING — mastert jeden Beat auf das Profil eines Profi-Referenztracks (Frequenzbalance, Lautheit, Stereobreite, Limiting). Ergebnis ~-12 LUFS (konkurrenzfähig laut, vorher leise -14), True Peak sicher bei -0,8 dBTP. Mood→Referenz: hell=Mero, tief=Pajel. Fallback bei Matchering-Fehler: alter loudnorm-Master → Pipeline bricht nie. Kosten: +~53s Rechenzeit/Beat auf dem Pi, kein Geld (läuft lokal).
SEO- & Qualitäts-Optimierung Runde 22026-06-19
19.06., zusaetzlich: (1) SEO-Titel nutzen jetzt den vollen 100-Zeichen-Platz — Format '[FREE] {Artist} Type Beat 2026 "{Name}" | {Mood} Trap Beat {BPM}bpm' → faengt zweite Suchbegriffe ab. (2) Text-Thumbnails (die 70% Rising-Artists ohne Foto) nutzen jetzt das echte FLUX-Hintergrundbild + Kuenstlername statt schlichtem Verlauf → deutlich hoehere Klickrate. (3) Auto-Playlists je Mood (playlists.json) — jedes Video wird einsortiert → mehr Wiedergabezeit + eigene rankbare Playlist-Seiten. Bestehende 4 Videos nachtraeglich einsortiert.
Reichweiten-Offensive umgesetzt (4 Hebel)2026-06-19
Reaktion auf die Diagnose, 19.06.: (1) Upload-Frequenz von 3×/Woche auf TÄGLICH (Cron 20:03) — mehr Such-Lose. (2) Neuer Artist-Pool RISING_ARTISTS (Osamason, Nettspend, 2hollis, Xaviersobased u.a.); Auswahl zu 70% aus diesem rankbaren Pool, 30% etabliert. (3) 2 Shorts pro Beat statt 1 (Ausschnitte bei 10s & 45s) — Shorts laufen 10× besser. (4) Kanal-Umbenennung in "Velvet Beats" geht NICHT per API (Privat-Account → Name kontogebunden) → bleibt Merts manuelle Aufgabe. Kostenfolge täglich: ~$0.40/Beat (Wan) + Suno/Gemini/FLUX → grob 3× höhere Lauf-Kosten als vorher.
Reichweiten-Diagnose — warum nur 5-7 Views2026-06-19
Live-Check 19.06.: Kanal hat 3 Abos, 13 Videos, ~3 Wochen alt. Haupt-Videos 2-7 Views, Shorts aber 31-63 Views (10× besser). Kernbefund: KEIN Bug — Type-Beat ist die meistumkaempfte Nische auf YouTube; ein 3-Abo-Kanal ohne Historie wird fuer Suchbegriffe wie "yeat type beat" schlicht nicht ausgespielt. 5-7 Views sind in den ersten Wochen normal. Echte Hebel: (1) Kanal-Branding fixen (heisst noch "Mert"/@mert5089), (2) mehr Uploads (taeglich statt 3×/Woche), (3) auf Shorts setzen — die funktionieren schon, (4) weniger uebermaechtige Kuenstler targeten, (5) Geduld: 3-6 Monate Konsistenz.
Animierter Loop-Hintergrund (Wan i2v + Ping-Pong)2026-06-17
Statisches FLUX-Bild wird per fal Wan 2.2 i2v zu ~5s Clip animiert → Ping-Pong-Loop (vor+rueckwaerts) laeuft endlos hinter Text/Audio. Warum Ping-Pong: Crossfade wirkte als harter Schnitt, End-Frame=Start killte die Bewegung. Ca. $0.40/Beat. Details: Skill beatfactory-loop-bg.
Standbild-Fallback bei Animations-Fehler2026-06-17
Schlaegt die Wan-Animation fehl (fal down/Timeout), faellt das Video sauber auf das FLUX-Standbild zurueck — die Pipeline bricht nie ab.
Tuple-Bug behoben (QC-Score leakte in ffmpeg)2026-06-17
Vertauschtes Tuple-Unpacking schob den QC-Score als Audio-Pfad in ffmpeg → Tag/Master + Video crashten. Reihenfolge korrigiert.
YouTube AI-Label schadet nicht2026-06-17
YouTube bestaetigt: KI-Kennzeichnung drosselt den Algorithmus nicht. Nicht kennzeichnen waere das eigentliche Risiko. Reichweite-Hebel sind SEO, Thumbnail und Konsistenz.
Cron statt systemd fuer diesen JobProjektstart 2026-05
BeatFactory-Cron (Di/Do/Sa 20:03) laeuft per klassischem crontab, kein systemd-Timer. Begruendung: einfacher, keine Service-Dateien noetig, reicht fuer 3×/Woche.
Offene Aufgaben für Mert
- TikTok/Instagram-Zugang für Shorts-Crossposting bereitstellen einmalig — Geplanter nächster Wachstums-Hebel: unsere YouTube-Shorts automatisch auch auf TikTok & Instagram Reels posten (dort entdecken Rapper Beats am meisten). Dafür brauche ich von Mert einen TikTok- und Instagram-Account für "Velvet Beats" + die jeweiligen Zugänge/API-Tokens (Instagram via Business-Account; auf dem Pi liegt bereits ein instapi-Projekt als Basis). Sobald die Zugänge da sind, baue ich das Crossposting in die Pipeline ein.
- YouTube-Kanal in "Velvet Beats" umbenennen einmalig — Der Kanal heisst aktuell noch "Mert" (Handle @mert5089, Privat-Account von 2014), obwohl Thumbnails, Beschreibungen und der Funnel-Link ueberall "Velvet Beats / @VelvetBeats" sagen. Folge: Wer draufklickt, sieht einen No-Name-Privatkanal mit 3 Abos, und der @VelvetBeats-Link in den Beschreibungen geht ins Leere. In YouTube Studio → Anpassen → Basisinfos den Kanalnamen auf "Velvet Beats" setzen und (falls frei) den Handle auf @VelvetBeats aendern. Wichtigster Branding-Hebel.
- BeatStars-Store einrichten und Link hinterlegen einmalig — BeatStars-Account anlegen (falls noch nicht vorhanden), Store aufsetzen und den Link in der .env-Datei als BEATSTARS_URL eintragen — damit er in den Beat-Beschreibungen auf YouTube erscheint.
Notizen
Stand 19.06.2026: Pipeline produktiv seit Ende Mai, letzter Upload "Silk" (Cochise x Lil Tecca, smooth, 138 BPM, D minor) am 18.06. Reichweiten-Check 19.06.: Kanal 3 Abos, 13 Videos; Full-Videos 2-7 Views, Shorts 31-63 Views (10× besser). Kein Bug — Type-Beat-Nische extrem umkaempft, kleiner Kanal wird kaum ausgespielt. Gegenmassnahmen umgesetzt: täglicher Upload, Rising-Artist-Pool (70%), 2 Shorts/Beat. WICHTIG offen (Mert): Kanal heisst noch "Mert"/@mert5089 statt "Velvet Beats" — per API nicht aenderbar (Privat-Account), nur manuell in YouTube Studio; bis dahin laufen Thumbnail-/Funnel- Branding und der @VelvetBeats-Link ins Leere. Thermal-Guard aktiv. Intermittierende Suno-Timeout-Fehler (Retry/Backoff offen). BeatStars-Link (BEATSTARS_URL) noch nicht gesetzt. KOSTEN (täglich ≈ 30 Beats/Mon, ALLES Pay-per-use, kein Abo): ~$16-19/Mon ≈ 15-18 €. Hauptposten fal Wan-Animation ~$0,40/Beat (~$12/Mon); Suno ~$0,06-0,10/Beat (PPU über Credits, 690 übrig ≈ ~70 Beats, Retries kosten extra); FLUX/Gemini Cent-Beträge; Pi-Strom ~$1. Matchering & 2. Short gratis (lokal). Exakter Credit→€-Kurs von Mert noch zu bestätigen.
Infrastruktur1
Pi-Basis🟢 läuftDie gemeinsame Grundinfrastruktur des Pi — gehört keinem einzelnen Projekt, hält aber alles am Laufen und zugänglich. Web-Zugang (Gateway + öffentlicher Funnel), geschützter Terminal-Login, die projektübergreifenden Sync-/Report-/Selbstheilungs-Jobs und das Canvas-Dashboard selbst.
Die gemeinsame Grundinfrastruktur des Pi — gehört keinem einzelnen Projekt, hält aber alles am Laufen und zugänglich. Web-Zugang (Gateway + öffentlicher Funnel), geschützter Terminal-Login, die projektübergreifenden Sync-/Report-/Selbstheilungs-Jobs und das Canvas-Dashboard selbst.
Automatisierungen
Notion-Aufgaben-Syncstündlich
Liest stündlich die Aufgaben aus allen Projekt-Manifesten und spiegelt sie in deine Notion-Liste „Aufgaben (Mert)". Hakst du eine Routine-Aufgabe ab, taucht sie zum nächsten Termin automatisch wieder auf.
Notion-Status-Synctäglich 06:00
Schreibt jeden Morgen den Gesundheits-Status (grün/gelb/rot) plus ein paar Kennzahlen jedes Projekts in deine Notion-Projektübersicht. Pausierte Projekte werden als „pausiert" gemeldet.
Canvas-Generatorper Timer
Baut die Daten der Projekt-Canvas neu: liest alle Manifeste plus Live-Zahlen aus den Datenbanken und erzeugt die Karte, die du im Dashboard siehst.
Wochen-Report (Telegram)So 19:07
Schickt dir Sonntagabend eine kurze Nachricht aufs Handy: wie geht es allen Projekten und welche Aufgaben sind offen — damit du nicht selbst nachschauen musst.
Realitäts-Check (Telegram)täglich 07:23
Prüft täglich still im Hintergrund, ob alles stimmt (Manifeste gültig, wichtige Jobs aktiv, keine Schlüssel im Klartext, genug Speicherplatz, Canvas frisch) — und meldet sich NUR bei Problemen.
Funnel-Selbstheilungnach Boot + täglich
Prüft, ob der Pi von außen (ohne Tailscale) öffentlich erreichbar ist, und repariert die Verbindung automatisch, falls sie hängt — inklusive Telegram-Hinweis.
Datenbank-Backuptäglich 03:11
Sichert nachts alle Projekt-Datenbanken in einen gemeinsamen Ordner (14 Tage Aufbewahrung), damit bei Versehen oder Defekt nichts verloren geht.
Bausteine der Pi-Basis
Gateway (Nginx)Web-Zugang
Routet jede Projekt-App + Landing-Seite; liegt unter /home/pi/gateway.
Terminal-LoginSicherheit
Passkey-Schutz (WebAuthn) vors Web-Terminal; /home/pi/terminal-auth.
Funnel + Selbstheilungöffentlich
Öffentliche HTTPS-Erreichbarkeit via Tailscale; repariert sich nach Ausfällen selbst.
Sync & ReportsAutomationen
Notion-Aufgaben/Status, Wochen-Report, Realitäts-Check, Canvas-Generator.
Wer/was arbeitet
Nginx-Gateway
Verteilt den Web-Zugriff auf alle Projekt-Apps (/pokepi/, /investpi/ …) + Landing-Seite
Terminal-Login (Passkey)
WebAuthn/Passkey-Schutz vors Web-Terminal (Face/Touch ID)
Tailscale-Funnel
macht den Pi öffentlich erreichbar (HTTPS) — mit Selbstheilung bei Ausfall
Web-Terminal
Browser-Shell mit Projekt-Sessions (eigenständig, localhost, Token-Auth)
Technik
Web-ServerNginx (System) · Tailscale Funnel (HTTPS öffentlich)
Login-SchutzWebAuthn/Passkey (terminal-auth, FastAPI)
Automationensystemd-Timer (Python-Skripte in /home/pi/scripts)
Aufgaben/WissenNotion (Aufgaben) · Canvas-Dashboard (Wissen)
Orte/home/pi/gateway · /home/pi/terminal-auth · /home/pi/scripts
Notizen
Diese Schicht ist bewusst projektübergreifend. Details/Wegweiser auch im Memory (pi-org-automation). Vor Echtgeld relevant — gehört mitgesichert und überwacht.
Nichts gefunden.