Schnell-Index — Projekt anklicken
Trading & Finanzen
🟢InvestPiAutonomes Aktien-Trading (Paper über Alpaca). Kernstrategie seit 2026-06 = regelbasierte…🟢DepotPiDepotPi verwaltet Merts echtes Revolut-Depot — das Geld, das wirklich investiert ist. Ke…🟢DayPiAutonomer Intraday-Day-Trader, Schwester-System zu InvestPi — aber Intraday statt Swing.…Creator-Tooling
🟢BeatFactoryBeatFactory ist eine vollautomatische KI-Musik-Fabrik auf dem Raspberry Pi: Sie erfindet…🟢ReelForgeAll-in-one-Werkbank für Reels: jede Art von Reel wird als eigenes Format eingehaengt, au…Infrastruktur
🟢Pi-BasisDie gemeinsame Grundinfrastruktur des Pi — gehört keinem einzelnen Projekt, hält aber al…🟢CorePiMerts persönliche Datenzentrale — Notizen, Aufgaben, Projekte, Ideen an einem Ort, als W…Trading & Finanzen3
InvestPi🟢 läuftAutonomes Aktien-Trading (Paper über Alpaca). Kernstrategie seit 2026-06 = regelbasiertes MOMENTUM — hält monatlich gleichgewichtet die 5 staerksten Aktien aus breitem Large-Cap-Universum. Fair backgetestet (2018-26, inkl. COVID- + 2022-Crash): schlaegt den Markt netto ~+16%/Jahr bei geringerem Drawdown. Das alte 20-Kennzahlen-Score-/Self-Learning-System wurde abgeloest (schlug den Markt nachweislich NICHT — Risiko-Vorhersage schlechter als ein Dummy). Lernen jetzt auf Strategie- Ebene (Varianten per Backtest validiert), nicht mehr Trade-fuer-Trade.
Autonomes Aktien-Trading (Paper über Alpaca). Kernstrategie seit 2026-06 = regelbasiertes MOMENTUM — hält monatlich gleichgewichtet die 5 staerksten Aktien aus breitem Large-Cap-Universum. Fair backgetestet (2018-26, inkl. COVID- + 2022-Crash): schlaegt den Markt netto ~+16%/Jahr bei geringerem Drawdown. Das alte 20-Kennzahlen-Score-/Self-Learning-System wurde abgeloest (schlug den Markt nachweislich NICHT — Risiko-Vorhersage schlechter als ein Dummy). Lernen jetzt auf Strategie- Ebene (Varianten per Backtest validiert), nicht mehr Trade-fuer-Trade.
Funktionsweise
- Quellen — yfinance (Kurse/Volumen) · FRED (Makro) — breites Large-Cap-Universum
- Momentum-Ranking — 6-Monats-Momentum je Aktie · Daten-Sanity + Mindestabdeckung + Cross-Check
- Top-5-Auswahl — 1×/Monat die 5 staerksten Titel, gleichgewichtet → Monatsziel
- Risk-Limits — AKTIV unter Momentum nur Kill-Switch + Circuit-Breaker (-30% v. 90-Tage-Hoch). Cash-Floor/Sektor-Cap/ Korrelation/Daily-Loss/Stop-Loss liegen im uebersprungenen Alt-Pfad — vor Echtgeld zu klaeren (s. tasks)
- Alpaca (Paper) — Konvergenz-Orders auf das Monatsziel, haelt die Positionen
- Monats-Check — automatischer Momentum-Report (monthly-digest) — Ziel eingehalten?
- Strategie-Lernen — Varianten per Backtest validieren (champion_duell / robustness) statt Trade-fuer-Trade
Automatisierungen
Trading (aktiv)
strategy-hourlyMo–Fr stündl. 10–21
Momentum-Rebalance: Monatsziel + Konvergenz.
rebalanceMo–Fr 21:30
Sell-only Pass (Stop/TP) zum Close.
monthly-dca1. d. Monats 14:00
Monatlicher Sparplan-Pick.
dca-watchdogtäglich 18:00
Überwacht DCA-Positionen auf Probleme.
Lernen (DEAKTIVIERT — Score-System)
outcomestäglich 02:30 · aktiv
Outcome-Messung + Drift-Erkennung (laeuft noch).
scoreAUS
Risk-Scoring aller Titel + Universe-Scan.
train-regimeAUS
HMM-Regime-Modell neu trainieren.
patternsAUS
Drawdown-Muster-Bibliothek aktualisieren.
meta-reviewAUS
Opus-Tiefenanalyse + Config/Code-Patches.
universe-screenerAUS
Neue Kandidaten screenen.
Reports
daily-reporttäglich 21:30
Tages-Performance via Telegram.
weekly-recapSo 19:00
Wochen-Recap (Hit-Rate, Best/Worst).
monthly-digest3. d. Monats 09:00
Monatlicher Momentum-/Verbesserungs-Digest.
weekly-mini-reviewAUS
Sonnet-Wochenanalyse (Score-System).
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)
Alpaca (Paper)
Broker — führt Trades aus, hält Positionen
Wer/was arbeitet
Momentum-Engine
Regel-Engine: 6-Monats-Momentum, Top-5 monatlich, gratis, keine LLM-Kosten
Opus 4.8
Strategie-Backtests + Audits (ad-hoc); autom. Meta-Reviews unter Momentum aus
Claude-Operator
setzt tiefere Verbesserungen autonom um, berichtet an Mert
Technik
SprachePython 3.11 (nativ, kein Docker)
Datenhaltung5× SQLite — trading, learning, market, alerts, patterns
Scheduling15 aktive systemd-Timer · User investpi (Score-System + rotation deaktiviert)
Marktdatenyfinance · fredapi (FRED)
ML / Regimehmmlearn (HMM) · scikit-learn — unter Momentum ruhend (train-regime aus)
BrokerAlpaca SDK (Paper-Account)
AlertsTelegram Bot API
Strategie-EngineMomentum (6-Mon, Top-5 monatl.) + Risk-Limits aus config.yaml
KI-ReviewsClaude Opus 4.8 (ad-hoc Backtests/Audits; autom. Reviews unter Momentum aus)
Deploygit auto-pull alle 2 Min → push = Live in <2 Min
Roadmap
KI-Swing-Trader (2. Paper-Konto) — Phase 1 Schatten laeuftgeplant
Eigener KI-Trader (LLM-Tilt) parallel zur Momentum-Engine, fair gemessen gegen Momentum + SPY/QQQ. Phasen - 0 Konto/Trennung, 0.5 News-Coverage-Test (Go/No-Go), 1 Schatten-Signal-Test (IC>0?), 2 det. Sicherheitskaefig, 3 Live-Paper >=3 Mon, 4 vorregistriertes Urteil nach 24-36 Mon. Lern-System nachgelagert. Konzept - AI_SWING_TRADER_CONCEPT.md. Blocker - 2. Alpaca-Konto durch Mert.
Live-Beweis sammelnlaufend
Momentum im Paper-Trading ueber Monate sauber gegen SPY/QQQ tracken — der Edge muss live halten, nicht nur im Backtest.
Universum bereits breit (geklaert)erledigt
Annahme 'Live-Universum eng/KI-lastig' war FALSCH - das galt der config.yaml-Ringliste, die nur Monats-DCA + tote Score-Engine speist. Die Live-Momentum-Engine handelt laengst den breiten 90-Namen-Korb. Erledigt - als einzige Quelle src/common/universe.py verankert; kein Wechsel noetig.
Cruft entfernterledigt
Tote Alt-Timer-Units aus Repo UND /etc entfernt (strategy/-open/-close, train-regime, patterns, meta-review, rotation = 13 Dateien); rotation-Timer abgeschaltet; Status-Monitoring von Score-Geistern befreit. Nichts Totes laeuft mehr - 15 aktive Timer, alle lebend. Score-Code bleibt als Referenz.
Momentum-Crash-Schutz (offen)ungeloest
200d-MA-Regime-Schalter GETESTET und VERWORFEN (whipsaw). Restrisiko 'echter Momentum-Crash' (2009-Typ) bleibt ungetestet, da 2018-26 keinen enthielt — billige Absicherung dafuer noch nicht gefunden (auch Low-Vol-Beimischung geprueft - diversifiziert echt (Korr 0,26), aber teuer an Rendite und im echten Crash-Fall mangels Daten ungetestet). Mitigation bis dahin — Paper bleiben, Live-Beweis ueber echten Zyklus abwarten.
Kosten-/Steuer-Realismusgeplant
DE-Steuer + Spreads/Slippage im Backtest haerter ansetzen, bevor die Echtgeld-Frage ernst wird.
Echtgeld-Entscheidoffen · Mert
Erst nach ueberzeugendem Live-Lauf ueber Zyklen inkl. >=1 Crash — Wertentscheidung von Mert.
Entscheidungen (Log)
Keine KI-Firma — stattdessen ehrlich messen und abspecken (mit Abschaltregel)
ENTSCHEIDUNG 2026-08-09. Mert hatte vorgeschlagen, das Projekt von einem KI-System wie eine Firma managen zu lassen (CEO, CTO, Abteilungen, 24/7-Ueberwachung) und die Entscheidung dann an Claude delegiert. ABGELEHNT in dieser Form. BEFUND: Momentum lag am 2026-08-09 bei -2,3 Prozent seit dem 29.04., der Markt (SPY) im selben Zeitraum bei +8,9 Prozent — 11,2 Punkte hinten, bei -15 Prozent groesstem Einbruch und negativem Sharpe. Der KI-Swing-Trader liegt seit dem 02.07. 4,9 Punkte hinten. Beide verlieren Geld in einem STEIGENDEN Markt; das ist kein Pech, sondern ein Konstruktionsfehler. BELEGE GEGEN DIE FIRMEN-IDEE: (1) Alpha Arena (nof1.ai) gab Ende 2025 sechs Spitzenmodellen je 10.000 Dollar ECHTES Geld — vier von sechs endeten tief im Minus (Claude und Gemini je ueber -40 Prozent, Grok -58 Prozent), Ursache durchweg kaputtes Risikomanagement; seit Dezember 2025 gibt es keine neue Runde. (2) Eine Untersuchung vom Juli 2026 zeigt, dass Agenten-TEAMS Einzelmodelle nicht zuverlaessig schlagen — bei gleichem Denkbudget ist ein Einzelagent meist gleich gut oder besser, und viele Multi-Agent-Systeme degenerieren still zu "einer arbeitet, der Rest macht Laerm". (3) Das meistkopierte Vorbild fuer die Idee (virattt/ai-hedge-fund, mit Analysten- und Portfoliomanager-Agenten) handelt laut eigener Anleitung ueberhaupt nicht echt und hat keine Erfolgsbilanz. (4) Rund 70 Prozent der Strategien, die im Rueckblick gut aussehen, fallen live durch — exakt unser Muster (7 von 9 Jahren im Backtest geschlagen, live 11 Punkte hinten). WAS DER IDEE RECHT GIBT: Der BETRIEB ist nachweislich das, was blutet — ein Circuit-Breaker-Fehlalarm fror die Engine 7 Tage ein, eine leere Kurszeile legte die Kursversorgung lahm, zehn Jobs scheiterten stumm, und der Marktvergleich war vier Wochen tot ohne dass es auffiel. Dort ist KI-Ueberwachung sinnvoll. NEUE LINIE: KI denkt und wacht, REGELN handeln. Keine Instanz entscheidet, welche Aktie gekauft wird. Rollen-Titel wie CEO/CTO werden nicht vergeben — ein Sprachmodell traegt keine Verantwortung, es klingt nur so. ABSCHALTREGEL (verbindlich, am 2026-08-09 auf Merts Einwand hin VERSCHAERFT): Liegt eine Strategie am 2026-10-31 mehr als 5 Punkte hinter dem SPY, wird sie ABGESCHALTET statt optimiert. Urspruenglich war der 2027-05-01 angesetzt. Mert wandte ein, dass neun weitere Monate zu grosszuegig sind fuer ein System, das in einem STEIGENDEN Markt Geld verliert. Die Gegenprobe stuetzt ihn: zwischen dem 13. und 20.07.2026 verlor das Momentum-Depot 6,5 Prozent, waehrend der Markt nur 0,9 Prozent nachgab — der Rueckstand kommt aus der AKTIENAUSWAHL, nicht aus den Betriebspannen. Damit faellt das Argument weg, ein laengerer Testlauf koenne das Bild drehen. Ueberwacht von scripts/abschalt_check.py (taeglicher Timer, meldet per Telegram sobald der Stichtag erreicht ist). Vorher festgelegt, damit das Ergebnis nicht nachtraeglich schoengeredet wird. Voraussetzung dafuer war der Benchmark-Fix am selben Tag.
Marktvergleich war 4 Wochen tot — Folgeschaden des Circuit-Breaker-Fixes
BEFUND + FIX 2026-08-09. Beim Circuit-Breaker-Fix am 2026-07-14 (PR #13, Glitch-Waechter im Equity-Snapshot) ging das Befuellen von spy_close verloren. Folge: Ab dem 14.07. schrieb kein Sync-Pfad mehr einen Vergleichswert, die Alpha-Berechnung in performance.py lief ins Leere, und das System konnte vier Wochen lang nicht sagen, ob es besser oder schlechter als der Markt laeuft. Der KI-Swing-Pfad (ai_swing_sync.py, seit 02.07.) hat NIE einen geschrieben. Aufgefallen ist es erst bei der Grundsatz-Diskussion am 09.08. FIX: Beide Sync-Pfade schreiben den SPY-Schluss wieder mit, ueber src/common/performance.py::current_spy_close(). Der Abruf ist fail-soft — faellt Yahoo aus, wird der Snapshot ohne Vergleichswert geschrieben, statt den Sync zu kippen. Die Luecke wurde rueckwirkend aus market.db gefuellt (2956 Zeilen), sodass beide Strategien eine lueckenlose Messreihe ab ihrem Start haben. LEHRE: Eine Kennzahl, die niemand aktiv prueft, kann monatelang tot sein. Die Abschaltregel haengt an genau dieser Zahl.
Aus dem Sparplan wird ein KI-Portfolio-Manager — eine Entscheidung pro Monat
ENTSCHEIDUNG 2026-08-01 (Mert). Auf den Befund, dass der Sparplan faktisch nie eine Auswahl traf, war die erste Antwort ein besserer Sparplan. Mert hat widersprochen und den eigentlichen Projektzweck klargestellt - eine KI soll auswaehlen und verwalten, nicht stumpf eine jahrzehntealte Regel auf einen Standard-ETF anwenden. Es soll ein PORTFOLIO-MANAGER sein. EINORDNUNG - der frueher belegte Misserfolg der Score-Aera widerlegte Kursvorhersage ("welche Aktie steigt naechsten Monat"), NICHT Depot-Verwaltung. Verwalten heisst - wissen warum jede Position da ist, monatlich pruefen ob der Grund noch gilt, entscheiden wohin neues Geld geht, und wann etwas raus muss. Das ist Urteil ueber Zusammenhaenge; genau das kann ein Sprachmodell und eine Momentum-Regel prinzipiell nicht. Zur Abgrenzung - DayPi ist ein Intraday-Daytrader (haelt nichts ueber Nacht, also das Gegenteil), die Momentum-Engine verwaltet zwar ein ganzes Depot, ist aber eine stumpfe Regel auf Spielgeld, und der KI-Swing-Trader ist ein Trader im Schattenbetrieb. Keins davon war ein Portfolio-Manager fuers echte Geld. DOMINIERENDE RANDBEDINGUNG (Mert, 2026-08-01) - Revolut gibt EINEN GRATIS-HANDEL PRO MONAT; jeder weitere kostet bis zu 2 Prozent von 50 EUR. Aktives Umschichten ist damit arithmetisch tot. Der Manager trifft deshalb GENAU EINE Entscheidung pro Monat - kaufen, verkaufen oder warten. Ein Verkauf verbraucht den Monatshandel und muss sich gegen "einen Monat lang investieren" rechnen, wird also nur bei gebrochener Anlage-These gemacht, nie wegen eines schlechten Kursmonats. VORGABEN von Mert - Verkaeufe erlaubt, mit Ansage per Telegram; max 25 Prozent je EINZELAKTIE, mindestens 4 Positionen. Breite Welt-/Index-ETFs sind von der 25-Prozent-Grenze ausgenommen, weil sie in sich gestreut sind - sonst wuerde die Regel ausgerechnet aus dem sichersten Baustein draengen (VWCE liegt bei 39,7 Prozent). BAUWEISE - die KI schlaegt vor, der CODE erlaubt. Alle Grenzen stehen in src/common/pm_rules.py und werden nach der Antwort hart geprueft; ein Verstoss faellt auf "diesen Monat nicht handeln" zurueck, statt die Grenze zu reissen. Neu - src/common/pm_context.py (vollstaendiges Lagebild - Depot mit Gewinn/Verlust und Gewicht, Bewertungskennzahlen, Quartalstermine, Nachrichten-Stimmung, Konjunktur, Marktbreite, Regime, Korrelation der eigenen Positionen; all das lag im Projekt bereits herum und wurde vom Sparplan nie benutzt), src/common/thesis_store.py (je Position eine Anlage-These PLUS ein pruefbares Widerlegungs-Kriterium, das jeden Monat wieder vorgelegt wird), scripts/portfolio_manager.py. Der Timer invest-pi-monthly-dca zeigt jetzt auf den Manager; der Unit-NAME bleibt absichtlich stehen, weil status_push.sh daran haengt. KOSTEN - ein Lauf kostet gemessen 0,22 EUR im Monat. Die Stunden-Bremse stand auf 0,20 EUR und haette den Job dauerhaft blockiert; sie wurde auf 0,60 EUR angehoben. Tages- (2 EUR) und Monatsgrenze (50 EUR) bleiben unveraendert.
Monats-Sparplan bekommt eine echte Auswahlgrundlage — VWCE war ein Zwangsergebnis, keine Entscheidung
BEFUND 2026-08-01 (Mert fragte, warum wieder VWCE vorgeschlagen wurde, obwohl der Kurs gerade nachgibt). Der Sparplan lief technisch fehlerfrei, traf aber faktisch keine Auswahl. Ursache - die Kandidatenliste kam aus den daily_score-Risk-Scores der letzten 24 Stunden. Diese Scores erzeugte zuletzt nur noch der DCA-Waechter um 18:00, und der bewertet ausschliesslich die BEREITS gehaltenen Positionen; der eigentliche Universum-Scan (invest-pi-score) ist seit Juni abgeschaltet. Die Liste bestand damit dauerhaft aus vier Werten (NVDA, ASML, PG, SPY). Die Kaufregel verlangte mindestens zwei Kandidaten mit composite unter 30 und Alarmstufe 0 — praktisch nie erfuellbar, also jeden Monat ETF-Rueckfall auf VWCE. Juli und August identisch. Die Telegram-Begruendung las sich wie eine Abwaegung, beschrieb aber eine Sackgasse. ZWEITER BEFUND - es wurde nie gemessen, ob die Empfehlungen besser waren als stumpf den Welt-ETF zu kaufen; damit war die Leitfrage des Projekts unbeantwortbar. ENTSCHEIDUNG - (1) neues Modul src/common/market_scan.py scannt lokal die rund 90 Large Caps des Momentum-Universums plus die drei Revolut-ETFs (Momentum 1/3/6/12 Monate, 12-1-Momentum, Abstand zum 200-Tage-Schnitt, Ruecksetzer vom 52-Wochen-Hoch, Schwankung, Sektor) — keine LLM-Kosten, Abdeckung aktuell 87 von 90; (2) neue Entscheidungsregel beruecksichtigt ausdruecklich, dass dieser Sparplan KEINE Rotationsregel hat - Einzeltitel nur bei durch 12-1-Momentum bestaetigtem Trend, tragbarer Schwankung und ohne Sektor-Klumpen, sonst ETF; (3) neues Modul src/common/dca_benchmark.py schreibt je Kauf den Einstiegskurs UND den gleichzeitigen VWCE-Kurs mit und rechnet Trefferquote, Differenz in Prozentpunkten und Euro-Effekt aus — Monate ohne echte Entscheidung zaehlen ehrlich als 0,0 Prozentpunkte. Die Bilanz steht ab sofort in jeder Sparplan-Nachricht. Der alte Score-Pfad bleibt nur noch als Zusatz-Info erhalten. NEBENBEFUND - Merts Praemisse stimmte nicht: VWCE lag -1,2 Prozent auf einen Monat, aber +19,9 Prozent auf zwoelf Monate und 7,4 Prozent ueber dem 200-Tage-Schnitt. Fallende Kurse sind fuer einen Sparplan ohnehin kein Aussetz-Grund, das steht jetzt explizit im Prompt.
PANNE 2026-08-01 — versehentlicher Zweitlauf des Sparplans, UNH-Fehlbuchung
Beim Umbau lief ein Test mit --dry-run versehentlich als Echtlauf, weil der Schalter zu dem Zeitpunkt noch nicht in der Datei auf der Platte war - der auto_pull-Timer hatte genau diesen Teil-Edit zurueckgedreht, waehrend andere Edits derselben Datei ueberlebten. Die alte __main__-Zeile ignorierte das Argument stillschweigend. Folge - eine zweite August-Buchung (UNH 50 EUR bei 421,02) im Sparplan-Ledger plus ein Telegram-Vorschlag an Mert. Beides ungueltig, UNH wurde wieder entfernt; der August-Sparplan ist mit VWCE erledigt. LEHRE - bei Skripten mit echten Seiteneffekten den Schutzschalter gegen die Datei auf der Platte pruefen, nicht gegen den zuletzt geschriebenen Edit; besser nur die neuen Funktionen einzeln testen, ohne den Buchungspfad zu betreten.
DCA-Depot kommt jetzt aus der config.yaml statt aus dem Empfehlungs-Protokoll2026-07-27
BEFUND 2026-07-27 (Mert per Broker-Screenshot) - das DCA-Depot im Dashboard stimmte nicht. Ursache - /api/dca baute das Depot aus dem Empfehlungs-Protokoll zusammen (alle feedback_reasons vom Typ dca_bought), also aus "was hat das System vorgeschlagen und wurde als gekauft markiert" statt aus dem echten Bestand. Das MUSS driften, sobald Mert etwas anderes kauft als vorgeschlagen oder etwas verkauft. Konkret vier Fehler - (1) ORCL stand noch mit -32% im Depot, obwohl am 10.07. verkauft; der Verkauf war als dca_sold sauber protokolliert, der Endpunkt fragte nur nie danach; (2) im Juli stand SPY drin, gekauft wurde VWCE - der Protokoll-Eintrag nannte sogar noch ein drittes Papier (XLV); (3) jede Position wurde pauschal mit 50 EUR angesetzt statt mit echten Stueckzahlen; (4) ASML wurde ueber die US-Variante bepreist (~1803 USD), gehalten wird die Amsterdamer in EUR (~1585) -> ~5% falscher Wert. Summe Dashboard 256,37 EUR vs Broker 229,84 EUR. FIX - Quelle ist jetzt der portfolio-Block der config.yaml (laut CLAUDE.md ohnehin die einzige Wahrheitsquelle fuer Depot-Daten); das Protokoll liefert nur noch die Begruendung zur Position. Verkaufte Positionen erscheinen getrennt als "closed", statt zu verschwinden - ein Fehlgriff, den man wegrechnet, verfaelscht die Frage, ob das System den Markt schlaegt. Neu ausserdem yf_symbol je Position (Boersenplatz != config-Schluessel) und die fehlenden Stueckzahlen fuer ASML/NVDA aus Merts Broker-Ansicht nachgetragen. NACHTRAG (gleicher Tag, Mert meldete weiterhin falsche Summe) - zwei Restfehler - (a) der Einstand war pauschal 4x50=200 EUR angesetzt, tatsaechlich hat Mert bei NVDA 51,08 und bei PG 50,83 eingezahlt, echter Einstand also 201,91 EUR; (b) der freie Saldo (0,10 EUR) fehlte ganz, der Broker zeigt als "Depotkonto" aber Positionen PLUS Saldo. Beides korrigiert, Saldo als settings.dca_cash_eur; er geht bewusst NICHT in Einstand/Rendite ein - uninvestiertes Geld hat keine Rendite. BELEGT - Einstand jetzt exakt 201,91 EUR wie beim Broker, Depotkonto-Summe auf 0,33 EUR genau (0,14%, reines Kurs-Timing: PG fiel zwischen Screenshot und Abruf um 1,74 USD). Lehre - ein Soll-Protokoll ist kein Ist-Bestand; wer beides vermischt, zeigt Positionen an, die es nicht gibt. Und Budget != Einstand - was Mert einzahlen WOLLTE ist nicht, was die Position gekostet hat.
Eine leere Yahoo-Kurszeile legte die gesamte Kursversorgung lahm - entschaerft2026-07-27
BEFUND 2026-07-27 (Routine-Check) - von 90 Titeln waren 0 bewertbar, die Kursversorgung war komplett tot. Ursache - Yahoo lieferte fuer Fr 24.07. eine Zeile mit Volumen, aber OHLC=NaN. Kette - _save_to_cache mappt NaN auf None, market.db hat NOT NULL auf close -> IntegrityError -> get_prices fliegt raus -> momentum_ranking faengt das per "except: continue" ab -> Datenabdeckung 0%. EINE kaputte Zeile eines Fremdanbieters riss also alle 90 Ticker mit. Wirkung - der Monats-Rebalance am 01.08. waere mit "zu wenig Daten" abgebrochen (immerhin laut, mit OnFailure-Alarm, kein stiller Freeze wie im Juli); /api/benchmark und /api/ai-swing/performance lieferten bereits 500 (NaN ist nicht JSON-kodierbar). Am Sonntag lief noch alles, weil der Cache als frisch galt und gar nicht aufgefrischt wurde - der Ausfall begann erst mit dem ersten fehlenden Handelstag. FIX - (1) _drop_incomplete_bars filtert Zeilen ohne Schlusskurs zentral in _rate_limited_fetch, also auf JEDEM yfinance-Pfad (voll + inkrementell); (2) zweiter Riegel in _save_to_cache laesst solche Zeilen aus, statt den ganzen INSERT platzen zu lassen; (3) beide SPY-Abrufe in der Webapp filtern NaN vor der Berechnung. Belegt - Datenabdeckung 0% -> 98%, Rebalance laeuft wieder durch. Die DB blieb sauber, die NOT-NULL-Sperre hatte die Daten geschuetzt (nur eben um den Preis des Absturzes). Lehre - Fremddaten koennen syntaktisch gueltig und inhaltlich leer sein; Filtern gehoert an die EINE Stelle, durch die alle Abrufe laufen, nicht in jeden Aufrufer.
Job-Liste der Systemseite kommt jetzt aus systemd statt aus einer Handliste2026-07-27
BEFUND 2026-07-27 - die Systemseite der Webapp pruefte eine hartkodierte Job-Liste, die nicht mehr stimmte - 5 Jobs existierten laengst nicht mehr, "invest-pi-strategy" hiess real "invest-pi-strategy-hourly", und alle 4 ai-swing-Jobs plus operator/monthly-digest fehlten ganz. Folge - der wichtigste Job stand dauerhaft auf Rot, obwohl er sauber lief, daneben 5 Geister-Jobs ebenfalls Rot. FIX - die Liste wird per systemctl list-unit-files aus systemd selbst gelesen, kann also nicht mehr veralten (20 Jobs erkannt, korrekt nur invest-pi-score als AUS). Lehre - Dauer-Rot macht einen echten Ausfall unsichtbar; eine Statusanzeige, die man von Hand nachpflegen muss, ist auf Dauer schlimmer als keine.
Circuit-Breaker-Fehlalarm fror Engine 7 Tage ein - gehaertet2026-07-14
BEFUND 2026-07-14 - die Momentum-Engine war seit 07-07 tot, ohne dass es jemand merkte. Ursache - Alpaca lieferte kurz "equity = nur Cash" (Positionen nicht geladen); der Circuit-Breaker las das als -98% Drawdown, schrieb data/.KILL und fror alles ein. Der Alarm ging ueber send_info -> unter ACTION_ONLY stumm, erreichte Mert nie. Derselbe Glitch schrieb Muell-Equity-Snapshots (2439$) und loeschte alle Positionen aus der DB (opened_at weg). FIX (PR #13) - (1) Plausibilitaets-Waechter im Circuit-Breaker - Drawdown < -60% ODER 0 gemeldete Positionen = Datenfehler, KEIN Kill (echter -30%-Crash eines 5-Titel-Depots erzeugt nie in einem Schritt < -60%); (2) echter Trip alarmiert jetzt via send_action_required (erreicht Mert); (3) sync_positions ueberspringt den Zyklus, wenn der Broker 0 Positionen trotz bestuecktem Depot meldet (kein Muell-Snapshot, keine Loeschung). SOFORT lokal - Fehlalarm-.KILL entfernt (Engine laeuft wieder), 3 Muell-Zeilen geloescht, opened_at auf 01.07. korrigiert. Lehre - ein stiller Not-Aus ist so gefaehrlich wie kein Not-Aus; kritische Halts brauchen einen lauten Kanal + einen Selbstheil-/Erkennungs-Pfad.
Deploy startet die Webapp jetzt selbst neu + 10 stumme Jobs bekommen Fehleralarm2026-07-27
BEFUND 2026-07-27 - zwei Luecken in der Betriebssicherheit. (1) auto_pull startete nach einem Deploy nichts neu. Bei den oneshot-Timern stimmt das (die holen den neuen Code beim naechsten Lauf), die Webapp laeuft aber DURCH und behielt ihren alten Code - teils ueber Wochen. Jede Webapp-Aenderung brauchte einen manuellen Neustart, den nur Mert ausloesen kann (investpi hat kein sudo dafuer). (2) Von 23 Services hatten nur 3 einen OnFailure- Alarm - u.a. rebalance (Stop-Loss-Pass!), sync (Broker-Abgleich) und backup konnten still ausfallen. FIX - (1) systemd_sync.sh bekommt einen zweiten Modus "--restart <unit>" gegen eine FEST VERDRAHTETE Liste (nur webapp + terminal); auto_pull ruft ihn, wenn der Pull webapp/ oder src/ angefasst hat. Die Liste ist bewusst hart - das Skript laeuft als root und sein Argument kaeme sonst aus einem Repo, das automatisch von GitHub zieht. Sudoers blieb unveraendert (die Regel erlaubt Argumente bereits). (2) OnFailure ergaenzt bei sync, rebalance, backup, outcomes, ai-swing, ai-swing-outcomes, monthly-dca, operator, dca-watchdog, auto-pull -> 13 von 23. Spam-Risiko ist gedeckelt, error_alert.sh hat 1h Cooldown pro Service. Bewusst OHNE Alarm - status-push, telegram-callbacks, hardware (alarmiert selbst) und die reinen Report-Jobs (ausbleibender Report ist selbst das Signal). Lehre - ein Deploy, der den laufenden Prozess nicht anfasst, ist nur ein halber Deploy.
DCA-Verkaufs-Alerts mit Aktions-Buttons + Ersatz-Vorschlag2026-07-10
Watchdog-Sell-Alerts liefen bisher ueber send_info und waren unter ACTION_ONLY stumm - erreichten Mert nicht. Neu: send_action_required mit Buttons verkauft/behalten. Verkauft -> Position raus aus config.yaml + dca_sold-Feedback (Watchdog stoppt) + automatischer Sonnet-Ersatzvorschlag (Einzeltitel/ETF) mit Kauf-Buttons. Handler dsell in telegram_callbacks. ORCL (bereits verkauft) aus der Ueberwachung genommen; PG bleibt. Via PR #12.
DCA-ETFs auf Revolut-kaufbare UCITS umgestellt (SPYL/VWCE/EQQQ)2026-07-03
Der monatliche DCA-Job durfte bisher nur US-ETFs empfehlen (SPY/QQQ/SMH/XLK/XLV/XLF) - in der EU auf Revolut NICHT handelbar, also fuer Mert totes Papier. Neu: nur 3 in EUR/Xetra auf Revolut kaufbare UCITS - SPYL.DE (S&P500), VWCE.DE (FTSE All-World), EQQQ.DE (Nasdaq-100); dca_fallback_etf SMH -> VWCE.DE. Zusaetzlich Bug behoben: bei ETF-Empfehlung wurde das Feld alternative_etf gebucht statt der empfohlenen ticker (Anzeige != Buchung). Telegram-Text jetzt immer "Monatlicher Invest-Vorschlag" (ETF o. Einzeltitel) statt "ETF-Fallback". Via PR #10.
KI-Swing live auf 2. Paper-Konto gegangen (Phase 3, mit Sicherheits-Käfig)2026-07-03
Ausfuehrungs-Adapter (scripts/ai_swing_execute.py) nimmt die juengste KI-Wochenentscheidung, baut einen gleichgewichteten Korb (max 12 Titel) und ordert aufs 2. Alpaca-Paper-Konto, strikt getrennt vom Momentum (source=ai_swing, strategy_label=ai_swing-v1). Sicherheits-Kaefig rein deterministisch, KI liefert KEINE Zahlen: Whitelist-Gate (fail-closed), 95% Invest / 5% Cash-Floor, 15%-Einzel-Kappe, nur aus Cash (nie Margin), Not-Aus .KILL_ai, Open-Order-Guard (keine gestapelten Orders bei geschlossener Boerse), Konto-DB-Abgleich vor jeder Order. Eigener Sync (ai_swing_sync.py) + Webapp-Ansicht KI-Swing (3-Wege-Vergleich vs Momentum vs SPY). BEWUSSTE Abweichung vom Konzept: live-paper VOR dem Schatten-IC-Nachweis gestartet, weil Mert echte Vorwaerts-Daten sehen will (Spielgeld, kein Geld-Risiko) - die Schatten-Messung laeuft parallel weiter. V1-Vereinfachung: gleichgewichtet statt ATR-Risiko-Sizing; voller Fuzzing- Haertetest (Konzept-Phase 2) noch OFFEN. Erster echter Kauf 2026-07-03 (9 Titel, Orders queued ueber Feiertags-Wochenende -> Fill Montag). Timer: execute So 16:30, sync stuendl. :40.
KI-Swing-Trader als 2. Paper-Konto geplant (Konzept festgehalten)2026-06-26
Ein zweiter, getrennter KI-Trader (LLM-Tilt) auf eigenem Alpaca-Paper-Konto soll fair gegen die Momentum-Engine UND SPY/QQQ antreten - Swing/Position (Tage-Wochen), abgegrenzt vom Intraday-DayPi. KI gibt NUR Namen+conviction+These aus, alle Zahlen/Stops/Caps macht deterministischer Code (kein LLM als Sicherheits-Gate). Ehrliche Erwartung: schlaegt Markt wahrscheinlich NICHT (Score-Aera + Forschungslage) -> billig bauen, fair messen, ohne Reue verwerfen. Bauplan korrigiert nach adversarialer Kritik: (1) Whitelist NICHT momentum-vorgefiltert (sonst Momentum-Klon, kann ihn nicht schlagen) -> breit nach Liquiditaet/Sektor; (2) billiger Schatten-Signal-Test (IC>0?) ZUERST, Kaefig erst danach; Lern-System erst wenn Phase 3 Puls zeigt, NICHT waehrend des Mess-Fensters (Stationaritaets-Freeze). Erfolgskriterium vorab einfrieren, Urteil erst nach 24-36 Mon. Volldetails: AI_SWING_TRADER_CONCEPT.md. STAND - 2. Konto angelegt+getestet, Erfolgskriterium eingefroren, News-Coverage-Test bestanden, Phase-1-Schatten gebaut (scripts/ai_swing_shadow.py + _outcomes.py, eigene DB data/ai_swing.db) und Tag-0-Entscheidung gesetzt. Umgesetzt 2026-07-03: live-paper aktiv, Timer scharf (s. neue Karte oben).
Risiko-Toleranz festgelegt - pur Momentum (kein Low-Vol-Blend)2026-06-24
Mert wuerde einen zwischenzeitlichen Drawdown von ~-35% aushalten ohne zu verkaufen. Daher bleibt es bei PUREM Momentum (volle Rendite), keine Low-Vol-Beimischung - die haette ~9 Punkte Rendite/J gegen ~5 Punkte weniger Drawdown getauscht, was sich nur lohnt, wenn man im Crash NICHT ruhig haelt. Caveat - auf Spielgeld leicht gesagt; echter Test ist ein echter Crash. Low-Vol-Werkzeug (factor2_lowvol_study.py) bleibt als Option im Schrank, falls sich das Verhalten live anders zeigt.
Cruft entfernt (Repo-Seite)2026-06-24
Tote Alt-Timer-Units (strategy/-open/-close, train-regime, patterns, meta-review) aus dem Repo ausgemustert, Status-Snapshot von toten 'score'-Eintraegen bereinigt, setup-Hinweis auf lebende Momentum-Timer korrigiert. Nichts Aktives betroffen (Smoke gruen). Score-Code bleibt Referenz. Live am Pi nachgezogen - rotation-Timer abgeschaltet + 13 /etc-Altlast-Dateien geloescht (sudo durch Mert).
Sicherungsluecke geschlossen2026-06-24
Lebende Units operator, monthly-digest, webapp, terminal lagen nur in /etc, NICHT im Repo - bei Neuaufsetzen via setup_pi.sh waeren sie verloren gewesen; jetzt byte-identisch versioniert. Dabei zwei weitere tote Score-/etc-Units gefunden (universe-screener, weekly-mini-review) - deaktiviert, schaden nicht, /etc-Purge per sudo noch offen.
Momentum scharfgeschaltet2026-06-23
engine=momentum ersetzt das Score-System. Grund - Score schlug den Markt nachweislich nicht (Risiko-Vorhersage schlechter als Dummy); Momentum lag 2018–2026 in 7/9 Jahren vorn bei geringerem Drawdown.
Weniger handeln, mehr halten2026-06-23
Backtest ueber Auf- und Abschwung — aktives Verkaufen war in KEINEM Regime besser als ruhiges Halten. Schutz kommt aus Diversifikation, nicht aus haeufigem Handeln. momentum_exit entschaerft.
Score-/Lern-Timer abgeschaltet2026-06-24
Self-Learning-Timer (score, regime, patterns, meta/mini-review, screener) deaktiviert — sie optimierten ein totes System und kosteten LLM-Geld.
Momentum produktions-gehaertet2026-06-24
Audit-Haertung - Daten-Sanity, Cross-Check, Mindestabdeckung, Circuit-Breaker, Market-Orders, Stale-Cleanup, atomarer State; nicht handeln solange Orders offen.
Universum verbreitert2026-06-23
Auf breite handelbare Large-Caps erweitert (u.a. CAT/TGT/GS/SLB) — mehr Auswahl fuer das Momentum-Ranking, weniger Klumpenrisiko.
Regime-Schalter verworfen2026-06-24
200d-MA-Filter (SPY unter Trend, dann Cash) per Backtest getestet (regime_overlay_check.py) — macht ALLES schlechter (2018-26 Rendite +30,5% auf +16,4%, MaxDD -18% auf -32%; Whipsaw - verkauft im Dip, verpasst Bounce). Bestaetigt - Timing schadet, Halten gewinnt. Momentum bleibt PUR.
Edge nach Steuer bestaetigt2026-06-24
tax_check.py - Momentum Top-5 netto +27,1%/J vs SPY +11,4%/J, also +15,8%/J Vorsprung NACH deutscher Abgeltungssteuer. Steuer frisst nur ~6 Punkte; Edge ueberlebt klar. Robustness - 7/9 Jahre und 70% der 12M-Fenster ueber Markt, MaxDD niedriger als SPY.
Zweiter Faktor (Low-Vol) geprueft - echte Diversifikation, aber teuer2026-06-24
Low-Vol als zweiten, von Momentum unabhaengigen Faktor backtestet (scripts/factor2_lowvol_study.py, Train/Test-Split + Korrelation). Korrelation der Monatsrenditen nur 0,26 - also echt unkorreliert. Eine 60/40-Mischung Momentum+LowVol senkt den MaxDD 2018-26 von -18% auf -13% bei minimal besserer Sharpe (1,15 vs 1,13) und besteht Out-of-Sample in BEIDEN Haelften. ABER kostet viel Rendite (21,6% vs 30,8%/J), weil LowVol in starken Momentum-Jahren hart bremst (2023 Momentum +58% vs Blend +26%). Und 2018-26 enthielt KEINEN Momentum-Crash - der eigentliche Schutznutzen bleibt ungetestet. Fazit - kein Selbstlaeufer, sondern Rendite-gegen-Ruhe-Abwaegung; Entscheidung vertagt auf Merts Risiko-Toleranz. Live unveraendert (pur Momentum).
Strategie-Varianten getestet, keine robuste Verbesserung2026-06-24
12-1-Momentum, Quartals-Rebalance und Ranking-Puffer geprueft (variant_check / turnover_buffer). Headline-Zahlen hoeher, aber nicht robust - 12-1 lumpy (schlaegt Markt nur 6/9 J vs 7/9), Quartal ist Mess-Artefakt, Puffer nicht-monoton (Rauschen). Lookback-Sweep 3-12M bestaetigt - Grundedge ist breit/robust. Live-Stand (6M Top-5 monatl.) bleibt - die 'Verbesserungen' waeren Overfitting.
Universum war nie der Hebel (Korrektur)2026-06-24
Erst vermutet - Live-Universum eng/KI-kuratiert (~41). FALSCH - das ist die config.yaml-Ringliste (nur DCA + tote Score-Engine). Die Live-Momentum-Engine nutzt seit jeher den breiten, branchen- gestreuten 90-Namen-Korb; Diversifikation also schon da. Einzige reale Schwaeche - der Korb lag in einer Backtest-Datei; jetzt eigene Quelle src/common/universe.py (Live+Backtest identisch). Verhalten unveraendert.
Live-Rückstand analysiert - kein Defekt, keine belegbare Verbesserung2026-08-18
Anlass - Live-Paper 29.04.-18.08.2026 nur -1,2% (USD) gegen SPY +8,8%, also ~10 Punkte Rückstand. BEFUND - die Ursache ist EIN Monat, nicht das System. Juli-Korb (AMD/CSCO/C/CAT/TXN) -8,3% gegen SPY +1,6%; klassischer Momentum-Reversal - die hoch-momentigen Titel kippten breit (MU -20%, INTC -28%, CAT -16%). August-Korb (AMD/CSCO/MU/INTC/UNH) +6,7% gegen SPY +2,0%, Engine also intakt. AUSFÜHRUNG SAUBER - Depot-Verlauf folgt dem Korb (Juli Depot -7,0% vs Korb -8,3%), Cash-Drag nur 2,5-4%, kein Leck. EINORDNUNG - im Backtest liegen 36% aller 4-Monats-Fenster hinter dem Markt, 6% davon >=10 Punkte, schlechtestes -19 Punkte. Der aktuelle Stand ist damit NORMALES Verhalten der bewiesenen Strategie, kein Signal. VARIANTEN GETESTET (Sweep 2018-26, beide Hälften, Jahres-Trefferquote) - Top-3 (35,0%/Sharpe 1,10), Top-5 LIVE (30,5%/1,13), Top-8 (24,6%/1,13), Top-10 (20,3%/1,00), Top-15 (21,3%/1,13), Sektor-Cap max2 bzw. max3 je Sektor (18,8-24,9%, MaxDD SCHLECHTER), 1/Vola-Gewichtung (16,9%/0,93). Top-5 gleichgewichtet ist Sharpe-Optimum UND Rendite-Optimum unter den robusten Varianten - jede Änderung wäre Verschlechterung. Top-8 bietet gleiche Sharpe bei MaxDD -15% statt -18%, kostet aber ~6 Punkte Rendite/J; bei Merts Zielsetzung (max. absolute Rendite) nicht gerechtfertigt. FEHLHYPOTHESE WIDERLEGT - Verdacht, der Live-Sanity- Filter MAX_6M_MOM=2,00 werfe echte Gewinner raus (Juli - MU +253% / INTC +241% wurden verworfen). Gegenrechnung - die echten Top-5 hätten im Juli -16,8% gemacht statt der gehaltenen -8,3%; der Filter hat GESPART. Backtest bestätigt - mit Cap 31,2%/Sharpe 1,17 vs ohne Cap 30,5%/1,13, griff in nur 5 von 101 Ticker-Monaten. Filter bleibt. ERGEBNIS - keine Änderung an der Strategie; der Rückstand ist auszusitzen, nicht wegzuoptimieren.
DayPi-Tab: Gesamt-Zeitverlauf ergänzt2026-08-18
Der DayPi-Tab zeigte nur den Intraday-Verlauf des laufenden Tages (equity_curve), der jede Nacht wertlos wird - ausserhalb der US-Marktzeit stand die Karte leer. NEU - Umschalter Gesamt/Heute im selben Kartenrahmen; Gesamt ist Standard und liest equity_history aus der DayPi-Datenbrücke (/home/pi/daytrader/data/daypi_public.json, welt-lesbar, Doku docs/webapp-datenbruecke.md bei DayPi). Ein Punkt je Handelstag als KATEGORIE-Achse gezeichnet, nicht als echte Zeitachse - Wochenenden/Feiertage fehlen in den Daten und würden sonst Lücken reissen. Fläche zwischen Kurve und Startlinie (100k) grün darüber / rot darunter, Crosshair samt Tooltip (Datum, Kontostand, P/L seit Start, Abstand zum Hoch), Kennzahlen Handelstage/Hoch/max. Rückgang im Kartenkopf. Reines SVG ohne neue Abhängigkeit, Neuzeichnen nur bei geänderten Daten (der Tab aktualisiert alle 2 s - sonst bräche der Hover ständig ab). Kein Backend-Eingriff nötig, /api/daypi spiegelt das Snapshot bereits vollständig.
Echtgeld bleibt gesperrtDauerregel
Kein echtes Geld vor Live-Beweis ueber mehrere Jahre + mind. 1 Crash. Bewusst konservativ.
Offene Aufgaben für Mert
- Stichtag Abschaltregel: schlaegt investpi den Markt? einmalig — Am 31.10. entscheiden: liegt eine Strategie mehr als 5 Punkte hinter dem Index, wird sie abgeschaltet. Der Pi meldet sich per Telegram.
- Revolut-Gebuehr fuer den zweiten Handel nachschauen einmalig — In der Revolut-App nachschauen, was ein zusätzlicher Handel in deinem Tarif kostet, und Bescheid sagen.
- Anweisungen des Portfolio-Managers ausfuehren und Abweichungen melden routine — Die Telegram-Anweisung vom 1. bei Revolut ausführen. Weichst du ab, kurz Bescheid sagen (Ticker, Stückzahl, Kurs).
- Sparplan-Umbau freigeben (PR mergen) und UNH ignorieren einmalig — UNH aus der Telegram-Nachricht vom 01.08. NICHT kaufen (Fehlbuchung). Auf GitHub den Branch fix/sparplan-echte-analyse als Pull Request mergen.
- Echtes DCA-Depot melden, wenn du selbst kaufst oder verkaufst routine — Selbst bei Revolut gekauft oder verkauft? Ticker, Stückzahl und Kurs melden, sonst zeigt das Dashboard ein falsches Depot.
- KI-Swing-Trader — Timer aktivieren (sudo) einmalig — Zwei systemd-Timer einmalig per sudo installieren — den Befehl gibt dir die InvestPi-Session.
- Monats-Check lesen routine — Den automatischen Momentum-Monatsbericht (Telegram, 3. d. Monats) kurz anschauen — laeuft die Strategie gegen den Markt wie erwartet?
- Echtgeld-Umstieg entscheiden einmalig — Wenn Momentum live ueber Zyklen inkl. mind. 1 Crash ueberzeugt hat — entscheiden, ob/mit wieviel echtem Geld gestartet wird. Erst dann, nicht frueher.
Notizen
EUR-denominiert, Paper-Trading. Ziel: maximale absolute Rendite — aber mit Risikoabwägung, nicht gepokert. GRUNDAUSRICHTUNG 2026-06-23: Backtests über Auf- (2025/26) und Abschwung (2022) zeigten, dass aktives Verkaufen in KEINEM Regime besser war als ruhiges Halten (Aufwärts +16% aktiv vs +20% halten; Bär -17% vs -15%). Schutz im Abschwung kommt aus Diversifikation, nicht aus häufigem Handeln. Daher momentum_exit (zuvor 63% aller Verkäufe) entschärft Richtung weniger Handeln / mehr Halten. Universe auf 29 handelbare Werte verbreitert (CAT/TGT/GS/SLB). 2026-06-23 SCHARFGESCHALTET: strategy_engine=momentum — Momentum-Top-5 (monatlich) ersetzt die alte Score-Pipeline (no-op), beide alten Handels-Pfade (run_strategy, weekly_rotation) delegieren/beenden. Belegt via champion_duell_fair / robustness_check / tax_check. Das alte Self-Learning des Score-Systems ist ruhend (Timer aus). Weiter Spielgeld; Echtgeld erst nach langem Live-Beweis. 2026-07-02 MANDAT: Projekt vollstaendig KI-gesteuert — Mert entscheidet NUR Echtgeld-Umstieg + Projektkosten; alle Technik- UND Strategie-Entscheidungen bei Claude. Claude-Entscheidungen aus dem Fable5-Audit (ohne Mert-Freigabe): (a) Live-Strategie wird an den validierten Backtest angeglichen — uebergewichtete Gewinner monatlich trimmen (Equal-Weight wie im Beweis-Backtest), Kurs-Cache-Adjustierungs-Bug fixen (monatl. force_refresh), Sanity-Filter per Zweitquelle cross-checken statt hart+dauerhaft droppen; JEDE Trading-Aenderung vorher via champion_duell_fair/robustness_check backgetestet, sonst kein Live. (b) Claude legt die im Momentum-Pfad aktiven Risiko-Grenzen fest — portfolio-orientiert (Daily-Loss + Drawdown-Tiers + Cash-Floor), Circuit-Breaker auf USD; bewusst KONSERVATIV/wenig-Verkaufen, da Backtests zeigten dass haeufiges Verkaufen die Rendite kostet. Beide Punkte in Arbeit — Ergebnis wird berichtet, nicht zur Freigabe vorgelegt. STAND 2026-07-02 UMGESETZT+committet: Equal-Weight-Trimming der Gewinner (gegen Live-Depot validiert — fand AMD ~932 EUR ueber Ziel), Momentum-Order-Logging in trades, Doppel-Order-/Storno-/stiller-Ausfall-Fixes, Circuit-Breaker auf USD, Kurs-Cache-Adjustierungs-Bug (Split/Dividende, deterministisch getestet), OnFailure-Ausfall-Alarm. Datei-Rechte 2026-07-02 auf investpi vereinheitlicht (chown) -> keine Sperren mehr. OFFEN (kein Mert-Input, NICHT dringend): portfolio-Risiko-Limits fuer den Echtgeld-Pfad (Design+Backtest, an die Echtgeld-Entscheidung gekoppelt), Sanity-Filter-Cross-Check, EUR-Einstands-Drift im Reporting, kleinere Live-Bugs. Voller Audit: reviews/2026-07-02_fable5_audit.md.
DepotPi🟢 läuftDepotPi verwaltet Merts echtes Revolut-Depot — das Geld, das wirklich investiert ist. Kein Kurs-Orakel und kein Handelsroboter: Der Job ist Risiko-Verwaltung. Es gibt eine schriftlich festgelegte Zielaufteilung über Anlageklassen, und die Aufgabe ist, das Depot mit möglichst wenigen Eingriffen dort zu halten. Nach der Neufassung vom 10.08.2026 gilt: 60 Prozent breit gestreute Welt-Aktien, 30 Prozent aktiv verwaltete Einzelaktien, 10 Prozent Anleihen — Aktienquote also 90 Prozent, auf Merts ausdrücklichen Wunsch nach mehr Risiko. Der Kern läuft seit dem 10.08.2026 vollautomatisch über zwei provisionsfreie Revolut-Sparpläne (80 EUR Welt-ETF, 20 EUR Anleihen, zusammen 100 EUR im Monat) und braucht keine Software. Was DepotPi tut, ist das Drumherum: den Bestand gegen Revolut abgleichen, die Sparplan-Raten nachziehen, die 30 Prozent Einzelaktien verwalten (Auswahl nach Geschäftsqualität, nicht nach Kursprognose) und ehrlich mitrechnen, ob das alles den simplen Welt-ETF schlägt. Tut es das über Jahre nicht, gehört es abgeschaltet.
DepotPi verwaltet Merts echtes Revolut-Depot — das Geld, das wirklich investiert ist. Kein Kurs-Orakel und kein Handelsroboter: Der Job ist Risiko-Verwaltung. Es gibt eine schriftlich festgelegte Zielaufteilung über Anlageklassen, und die Aufgabe ist, das Depot mit möglichst wenigen Eingriffen dort zu halten. Nach der Neufassung vom 10.08.2026 gilt: 60 Prozent breit gestreute Welt-Aktien, 30 Prozent aktiv verwaltete Einzelaktien, 10 Prozent Anleihen — Aktienquote also 90 Prozent, auf Merts ausdrücklichen Wunsch nach mehr Risiko. Der Kern läuft seit dem 10.08.2026 vollautomatisch über zwei provisionsfreie Revolut-Sparpläne (80 EUR Welt-ETF, 20 EUR Anleihen, zusammen 100 EUR im Monat) und braucht keine Software. Was DepotPi tut, ist das Drumherum: den Bestand gegen Revolut abgleichen, die Sparplan-Raten nachziehen, die 30 Prozent Einzelaktien verwalten (Auswahl nach Geschäftsqualität, nicht nach Kursprognose) und ehrlich mitrechnen, ob das alles den simplen Welt-ETF schlägt. Tut es das über Jahre nicht, gehört es abgeschaltet.
Funktionsweise
- Depot-Stand — eigene Datenbank ausserhalb jedes Git-Repos, regelmässig gegen Merts Revolut-Ansicht abgeglichen
- Kurse — Tageskurse je Position plus Wechselkurs — die einzige externe Quelle, die geblieben ist
- Marktwert-Gewichte — Anteile werden nach heutigem Wert gerechnet, nie nach Kaufpreis
- Soll-Ist-Vergleich — Abweichung je Anlageklasse gegen die Zielaufteilung — reine Rechnung, kein Sprachmodell
- Sparplan-Raten — wie die 100 EUR im Monat zu verteilen sind, damit das Depot aufs Ziel zuläuft
- Anlage-These je Einzelaktie — warum gekauft + woran erkenne ich, dass der Grund fällt
- KI-Urteil über die Satelliten — gilt die These noch, fehlt eine Branche, wer kommt rein, wer raus
- Harte Leitplanken — max 8 Prozent je Einzelaktie, höchstens 5 Titel — der Code erlaubt oder verbietet
- Telegram an Mert — nur wenn wirklich etwas zu tun ist; ein Monat ohne Meldung ist der Normalfall
- ETF-Messlatte — geht ungefragt mit jeder Meldung raus — schlägt das hier den Welt-ETF oder nicht?
Automatisierungen
ETF-Sparpläne bei Revolutmonatlich, automatisch — 80 EUR Welt-ETF (VWCE) + 20 EUR Anleihen (AHYD)
Monatsrechnung3. des Monats 18:00 (cron als Nutzer depotpi)
Bestands-Abgleichgeplant: Bestand gegen Merts Revolut-Ansicht prüfen
InvestPis Monats-Job + Wächteram 10.08.2026 stillgelegt (Timer deaktiviert, Code bleibt liegen)
Neufassung — DepotPi als Risiko-Verwalter
Ausgangsbefund — das heutige Depot ist keine Streuungaus Revolut belegt
Stand 10.08.2026, aus Merts Revolut-Depotansicht (nicht mehr aus InvestPis Buchhaltung, die falsch war). Marktwert 276,36 EUR plus 0,26 EUR Barsaldo; eingesetzt wurden 249,81 EUR, macht +10,6 Prozent. Fünf Positionen nach Marktwert: ASML 65,70 (23,8 Prozent), NVDA 59,78 (21,6), PG 51,85 (18,8), VWCE 50,89 (18,4), UNH 48,14 (17,4). Damit stecken 81,6 Prozent in Einzelaktien und nur 18,4 Prozent im breit gestreuten Welt-ETF. Allein die zwei Halbleiterfirmen ASML und NVDA halten 45,4 Prozent; mit dem Tech-Anteil des Welt-ETF hängen 50 Prozent des Depots an Technologie. Anleihen, Gold oder irgendetwas, das nicht mit Aktien fällt: 0 Prozent. Die Streuungsforschung nennt 25 bis 50 Einzeltitel, bevor firmenspezifisches Risiko verschwindet — mit 5 Positionen ist das unerreichbar. Anzuerkennen bleibt: Der UNH-Kauf des Portfolio-Managers war inhaltlich richtig, er brachte eine fehlende Branche ins Depot
Baustein 1 — Zielaufteilung, offensive Fassung (10.08.2026)entschieden
60 Prozent Welt-Aktien · 30 Prozent Einzelaktien (Satelliten, höchstens 5 Titel, je max 8 Prozent) · 10 Prozent Anleihen · Gold vorerst 0. Aktienquote damit 90 statt 75 Prozent. Sparrate 100 EUR im Monat, davon per Sparplan 80 EUR Welt-ETF und 20 EUR Anleihen. Das ist der Maßstab, gegen den jeden Monat gemessen wird — das Gegenstück zum Investment Policy Statement der Profis. Kern-Satellit-Aufbau im Verhältnis 70 zu 30, laut Literatur die bekannteste Variante und für Anleger mit höherer Risikotoleranz vorgesehen. Abweichung von mehr als 10 Prozentpunkten nach oben ist der einzige Verkaufsgrund neben einer gebrochenen These. Fünf Titel statt vier, weil Merts vier bestehende Aktien bleiben und ein Platz für eine neue Auswahl durch DepotPi frei sein soll
Baustein 2 — Monatsentscheidung wird reiner Codeentwurf
Welche Klasse liegt am weitesten unter ihrem Zielgewicht? Dorthin die 50 EUR. Ein Kauf, kein Verkauf, keine Gebühr, keine Steuer — und antizyklisch, weil automatisch das gekauft wird, was zuletzt gefallen ist. Braucht kein Sprachmodell und ist damit überprüfbar. Belegt wirksam genau dann, wenn die Sparrate groß ist im Verhältnis zum Depot: 50 EUR sind hier 17 Prozent des Depotwerts. Seit dem Sparplan-Fund vom 10.08.2026 gilt zusätzlich: Der Kern kann auch auf mehrere Klassen gleichzeitig verteilt werden, weil ETF-Sparpläne nichts kosten. Ob DepotPi das nutzt oder bei einer Klasse pro Monat bleibt, ist noch offen — für den Umbau in die Zielaufteilung ist Aufteilen schneller, für die Nachvollziehbarkeit ist eine Entscheidung pro Monat klarer
Baustein 3 — der Satelliten-Manager (das eigentliche DepotPi)entwurf
Seit der offensiven Ausrichtung ist das die Hauptaufgabe: 30 Prozent des Depots werden aktiv verwaltet, höchstens 5 Titel, je höchstens 8 Prozent. Fünf konkrete Aufgaben — Auswahl neuer Titel, wenn ein Platz frei ist; monatliche Prüfung, ob die hinterlegte These noch gilt; Austausch bei gebrochener These; Nachkauf, wenn der Satelliten-Anteil unter 30 Prozent fällt; Deckelung, wenn ein Titel über 8 Prozent wächst. AUSWAHLKRITERIEN sind ausdrücklich KEINE Kursprognose (die ist in InvestPis Backtests 2026-06 widerlegt), sondern Geschäftsqualität: dauerhafter Wettbewerbsvorteil, verlässlicher freier Mittelzufluss, Bewertung im Verhältnis zur Ertragskraft, und welche Branche im Depot fehlt. Dazu je Titel eine These und ein prüfbares Widerlegungs-Kriterium. Daneben bleiben die Fragen, die eine Regel nicht beantwortet: Läuft das Depot in Wirklichkeit im Gleichschritt, obwohl die Prozentzahlen nach Streuung aussehen? Hat sich an Merts Lage etwas geändert, das die Zielaufteilung selbst infrage stellt?
Warum der Satellit erst in 5 Monaten Arbeit machtgerechnet
Merts vier Einzelaktien machen heute 81,6 Prozent des Depots aus — weit über den 30 Prozent Ziel. Bis dahin wird nichts nachgekauft, sondern verwässert: Bei 100 EUR Sparrate im Monat fällt der Satelliten-Anteil nach rund 5 Monaten unter 30 Prozent, das Depot liegt dann bei etwa 776 EUR. Ab da beginnt die aktive Auswahl. Bei der zuvor geplanten defensiven Variante mit 20 Prozent Satellit hätte das 9 Monate gedauert — die offensivere Ausrichtung bringt DepotPi also fast doppelt so schnell in die eigentliche Arbeit
Erste belastbare Messung — knapp vor dem Welt-ETFgemessen 11.08.2026
Grundlage ist Merts Revolut-Umsatzliste; alle Daten wurden gegen die historischen Marktkurse gegengeprüft (Abweichung unter 1 Prozent). Ergebnis: 298,65 EUR eingesetzt, heutiger Stand plus realisierte Erlöse 322,11 EUR. Dieselben Beträge zu denselben Zeitpunkten stumpf im Welt-ETF hätten 320,00 EUR ergeben — die Auswahl liegt also 2,11 EUR beziehungsweise 0,71 Prozentpunkte vorn. Bei sechs Geschäften über ein halbes Jahr ist das Rauschen, kein Beweis für Können. ZWEI KORREKTUREN, die diese Zahl erst möglich gemacht haben. Erstens: Die Kaufdaten aus dem Vorgängersystem waren falsch — ASML und NVIDIA standen dort mit Januar 2025, gekauft wurden sie am 27.03. und 26.02.2026. Die frühere Angabe "0,99 EUR hinter dem Welt-ETF" ist damit zurückgezogen. Zweitens: In der Umsatzliste tauchte eine Position auf, die in keinem Bestand mehr steht — Oracle, am 01.05.2026 gekauft und am 30.06.2026 mit Verlust verkauft. Allein dieses Geschäft liegt 8,67 EUR hinter dem ETF. Ohne es sähe die Bilanz mit +10,78 EUR glänzend aus. Genau deshalb rechnet die Messlatte verkaufte Positionen mit, und zwar bis zum Verkaufstag statt bis heute: Wer nur misst, was noch im Depot liegt, blendet jeden Verlust aus und rechnet sich systematisch reich.
Baustein 4 — Messlatte bekommt eine zweite Dimensionentwurf
Der Vergleich gegen "immer nur den Welt-ETF" bleibt die Existenzberechtigung des Projekts. Neu: nicht nur Rendite, sondern auch Schwankung. Ein Depot mit gleicher Rendite bei weniger Ausschlägen hat gewonnen — genau das ist Merts erklärtes Ziel
Sonderauflage, weil Mert den Empfehlungen folgt statt sie zu prüfenpflicht
Mert hat am 10.08.2026 gesagt, dass er handelt, wie das System empfiehlt. Damit fällt die zweite Instanz weg, die einen Systemfehler abfangen würde — jeder Fehler wird sofort zu echtem Verlust. Zwei Konsequenzen sind ab jetzt Pflicht, nicht Kür. Erstens: Die Bilanz gegen den Welt-ETF geht JEDE Monatsnachricht mit raus, ungefragt und auch wenn sie schlecht aussieht — sonst merkt Mert erst nach Jahren, wenn das System schlechter ist als Nichtstun. Zweitens: Jede Empfehlung muss in einem Satz begründet sein, den Mert beurteilen kann. Eine Empfehlung, die er nur ausführen, aber nicht nachvollziehen kann, ist in diesem Aufbau ein Konstruktionsfehler
Umbau braucht keinen einzigen Verkaufgerechnet
Bei gleichbleibenden Kursen allein durch Nachkaufen gerechnet, Stand nach UNH-Bestätigung: Der Einzelaktien-Anteil fällt von 66,9 Prozent (heute) auf 44,7 nach 3 Monaten, 33,5 nach 6, 22,4 nach 12 und 20,1 nach 24 Monaten — also genau auf die Zielmarke. Null Verkäufe, null Gebühren, null verbrauchte Gratis-Handel. Die Rechnung zeigt die Mechanik der Sparrate, nicht eine Kursprognose
Verkauf bleibt der Ausnahmefallentwurf
Genau zwei zulässige Gründe: eine Anlage-These ist nachweislich gebrochen, oder eine Klasse liegt trotz monatelangem Nicht-Nachkaufen mehr als 10 Prozentpunkte über dem Ziel. Alles andere wird ausgesessen. Deckung durch die Forschung: häufiges Nachjustieren verbesserte in Vanguards Rückrechnung bis 1926 weder Rendite noch Risiko, es erhöhte nur Umschlag und Kosten
Bausteine auf Revolut — Stand der Suche 10.08.2026teils gefunden
Mert hat in der App gesucht. Gefunden, aber beide in der jeweils FALSCHEN Variante. ANLEIHEN: 8OUU (Amundi Global Agg SRI UCITS ETF DR, LU2439734141, TER 0,14) ist UNGESICHERT. Bei Weltanleihen dominiert dann das Währungsrisiko den Anleihenertrag — der ruhige Baustein wird zum schwankenden und verfehlt seinen Zweck. Gebraucht wird die gesicherte Variante: Kürzel AHYD, LU2439733507, TER 0,16. GOLD: IGLD (iShares Physical Gold EUR Hedged ETC) ist GESICHERT — bei Gold ist das die schlechtere Wahl. Die Währungskomponente ist Teil des Schutzes (der Dollar steigt typischerweise, wenn Aktien fallen), und die Sicherung kostet die Zinsdifferenz, rund 0,20 bis 0,25 Prozent pro Jahr obendrauf. Besser ist die ungesicherte Variante: Kürzel IGLN oder SGLN, IE00B4ND3602, TER 0,12. MERKSATZ: Anleihen sichern, Gold nicht. Klingt widersprüchlich, ist es nicht — bei Anleihen ist die Währung ein Störgeräusch, bei Gold ein Teil der Wirkung. WARNUNG: Die Revolut-Suche nach "gold" liefert ganz oben CFDs (Barrick Gold CFD, SPDR Gold Trust CFD, XAU:CFD). Das sind gehebelte Wetten mit Totalverlustrisiko und haben in diesem Depot nichts zu suchen. Ebenfalls nicht gemeint ist XAU, das Rohstoff-Gold direkt im Revolut-Konto — kein Wertpapier, liegt nicht im Depot.
Warum weniger Daten hier besser sindbegründung
Aus rund 190 KB umzugspflichtigem Code werden geschätzt 40. Es bleiben: Kurse, Wechselkurs, Gleichlauf-Rechnung, Anlage-Thesen der Satelliten, Depot-Buchführung. Der tiefere Grund ist nicht Aufräumen: Jede Warnsignal-Quelle ist eine Einladung zu handeln, und laut Morningstar kostet genau dieses Verhalten Anleger 1,2 bis 1,7 Prozentpunkte pro Jahr — mehr, als Titelauswahl bei dieser Depotgröße je einbringen kann
Daten & Quellen
Revolut (manuell)
Merts echter Depot-Bestand — Screenshot oder Umsatzliste. Die einzige Wahrheit, alles andere ist eine Kopie davon
Kursdaten (Yahoo)
Tages-Schlusskurse der gehaltenen Titel plus Wechselkurs Euro/Dollar, per JSON-Aufruf ohne Zusatzpaket
Wer/was arbeitet
Soll-Ist-Rechnung
reiner Code — Abweichung und Sparplan-Raten, nachrechenbar und kostenlos
Leitplanken-Prüfung
reiner Code — erlaubt oder verbietet, was das Sprachmodell vorschlägt
Satelliten-Manager
Sprachmodell — Auswahl und Überwachung der 30 Prozent Einzelaktien nach Geschäftsqualität
ETF-Messlatte
reiner Code — Vergleichsrechnung gegen den Welt-ETF, geht ungefragt mit raus
Technik
SprachePython 3.13 (nativ, kein Docker)
Abhängigkeitennur PyYAML — Kurse kommen über einen JSON-Aufruf gegen Yahoo, kein yfinance/pandas/numpy (rund 100 MB gespart, für eine Handvoll Kurse im Monat)
Aufbaudepot.yaml = Anlagepolitik (Ziel, Grenzen) · data/depot.db = Bestand · src/{storage,kurse,bestand,ziel}.py · scripts/stand.py
Stand anzeigenpython3 scripts/stand.py — Bestand, Abweichung, empfohlene Sparplan-Raten, Leitplanken-Warnungen
Nutzereigener Systemnutzer depotpi — abgeschottet, weil echtes Geld dranhängt
Ordner/home/depotpi/depot-pi
Sessiontmux depotpi
StorageSQLite in data/depot.db — bewusst AUSSERHALB jedes Git-Repos, damit kein Deploy-Mechanismus eine Buchung überschreiben kann
MeldewegTelegram über InvestPis Bot — DepotPi SENDET nur und holt nichts ab, deshalb kein Konflikt mit dessen Poller. Antwort-Knöpfe brauchen später einen eigenen Bot
Uebergangsrechtdepotpi ist in der Gruppe investpi (Leserecht für den Umzug) — danach entfernen
Fahrplan
✅ Phase 0 — Gerüst
Eigener Nutzer + Ordnerfertig
Systemnutzer depotpi, /home/depotpi/depot-pi, abgeschottet wie InvestPi
Eigene tmux-Sessionfertig
Session depotpi — eigener Chat, eigener Kontext, kein Vermischen mit InvestPi
Registriertfertig
Dashboard-Kachel, Handbuch, Aufgaben-Sync nach Notion
🔨 Phase 1 — Umzug aus InvestPi
Neufassung ist in Kraft — Kern läuft bereitsfertig
Am 10.08.2026 hat Mert die Neufassung nicht nur freigegeben, sondern gleich umgesetzt: Zielaufteilung steht (60/30/10, Aktienquote 90 Prozent), beide ETF-Sparpläne laufen mit zusammen 100 EUR im Monat. Der Kern des Depots wächst damit ohne jede Software. Was DepotPi noch bauen muss, ist deutlich weniger als der ursprünglich geplante Umzug
InvestPis Monats-Job stillgelegtfertig
Am 10.08.2026 erledigt. invest-pi-monthly-dca.timer und invest-pi-dca-watchdog.timer sind deaktiviert und aus der Timer-Liste verschwunden — geprüft. Der Code drüben bleibt als Referenz liegen, gelöscht wird nichts. Damit kann am 01.09. nichts mehr in die kaputte Buchhaltung schreiben, und der tägliche Wächter kostet keine KI-Aufrufe mehr
Bestandsaufnahmefertig
Erledigt am 10.08.2026. 7 Kern-Dateien (~73 KB) gehören eindeutig hierher, sie hängen an 13 geteilten Bausteinen (~110 KB) plus 6 weichen Datenquellen. Ergebnis siehe Ansicht "Was genau umzieht"
Depot-Bestand geklärt und in eigener Datenbankfertig
Am 10.08.2026 aus Merts Revolut-Ansicht übernommen: 276,36 EUR Marktwert, 249,81 EUR eingesetzt, fünf Positionen. Beide Buchungsfehler vom 01.08. sind damit aufgelöst (VWCE-Phantom raus, UNH rein). Liegt jetzt in data/depot.db ausserhalb jedes Git-Repos
Gemeinsame Bausteine entscheidenoffen
Kursdaten, Risiko-Bewertung, Nachrichten, Marktbreite, KI-Anbindung, Telegram nutzen beide. Pro Baustein: eigene Kopie oder gemeinsam nutzen? Kopie = unabhängig aber doppelte Pflege; gemeinsam = schlank aber gekoppelt
Eigene Datenbankoffen
Depot-Historie, Anlage-Thesen, Empfehlungs-Protokoll und ETF-Vergleich aus InvestPi herauslösen (dortige Datenbanken sind ~670 MB und voll mit Momentum-Daten, die hier nichts zu suchen haben)
Eigener Depot-Standoffen
Der echte Revolut-Bestand steht heute in InvestPis Konfiguration — muss hierher, sonst gehört das Depot weiter InvestPi
Eigener Telegram-Wegoffen
Die Antwort-Knöpfe (gekauft/ETF/übersprungen, verkauft/behalten) hängen an InvestPis Bot-Poller — eigener Weg oder sauber geteilt
Eigene Zeitpläneoffen
Zwei Timer umhängen: Monats-Entscheidung (1. um 14:00) und Depot-Wächter (täglich 18:00)
Parallellauf + Abschaltungoffen
Erst gegenprüfen, dass beide dasselbe Ergebnis liefern — dann bei InvestPi abschalten. NICHT vorher
🔭 Phase 2 — eigenständig weiterentwickeln
Eigene Depot-Ansichtspäter
Die DCA-Ansicht steckt heute in InvestPis Dashboard — eigene Oberfläche oder Kachel im Hub-Dashboard
ETF-Messlatte sichtbar machenspäter
Die ehrliche Frage dauerhaft beantworten: schlägt der Manager den simplen Welt-ETF? Wenn nicht über Jahre — dann ist das Projekt widerlegt und gehört abgeschaltet
Entscheidungen
Offensivere Ausrichtung auf Merts ausdrücklichen Wunschneu · Merts Entscheidung
2026-08-10. Mert hat nach der ersten Fassung ausdrücklich mehr Risiko verlangt und das nach meinem Einwand wiederholt: "ich würde aber gerne etwas mehr risiko in meinem portfolio haben und dazu sollte depotpi dienen, im endeffekt mein portfolio manager". Das ist seine Entscheidung und wird umgesetzt. Umgesetzt wird sie dort, wo Risiko VERGÜTET wird: Aktienquote von 75 auf 90 Prozent (Anleihen 15 auf 10, Gold vorerst raus) und Satelliten-Anteil von 20 auf 30 Prozent. NICHT umgesetzt wurde Merts ursprünglicher Vorschlag, monatlich 50 EUR fest in eine Einzelaktie zu stecken — das hätte langfristig auf 50 Prozent Einzelaktien geführt und ist unkompensiertes Risiko: Firmenspezifisches Risiko lässt sich gratis wegstreuen, deshalb zahlt der Markt dafür keine Prämie. Der Preis der Entscheidung, offen benannt: Bei 90 Prozent Aktienquote ist ein Rückschlag von 45 Prozent im Bereich des historisch Möglichen (100 Prozent Aktien kamen auf -49, ein 60/40-Depot auf -27 bis -40). Und der Entnahme-Topf für Merts 5-bis-10-Jahre-Fenster schrumpft auf 10 Prozent — nimmt er in einem schlechten Jahr Geld heraus, muss er womöglich Aktien im Tief verkaufen. Vertretbar nur, weil sein Notgroschen ausserhalb des Depots liegt und der Entnahmezeitpunkt flexibel ist.
Anlage-Thesen für alle vier Einzelaktien nachgetragen und bestätigtneu · erledigt
2026-08-11. Merts vier Aktien wurden ohne dokumentierten Grund gekauft ("das System hat sie vorgeschlagen") — damit gab es kein Kriterium für einen Verkauf ausser dem Kursverlauf. Thesen und Widerlegungs-Kriterien sind auf Basis des heutigen Geschäftsstands nachgetragen und von Mert bestätigt; sie liegen in der Tabelle "thesen" der eigenen Datenbank. ZWEI STEHEN NICHT GUT DA, das ist das eigentliche Ergebnis: Bei NVIDIA läuft das Widerlegungs-Kriterium bereits — der Marktanteil bei KI-Beschleunigern sinkt von über 95 in Richtung 75 Prozent, AMD wuchs im Rechenzentrum um 57 Prozent. Bei Procter & Gamble lieferte die Preissetzung im Geschäftsjahr 2026 erstmals seit vier Jahren keinen Wachstumsbeitrag mehr. Beide sind noch nicht gebrochen, gehören aber ab sofort eng beobachtet. KORREKTUR am Vorgängersystem: Dessen UNH-These nannte "sinkende Mitgliederzahl" als Widerlegung. Untauglich — UnitedHealth verliert derzeit über 3 Millionen Mitglieder, aber absichtlich durch den Rückzug aus unprofitablen Märkten, und genau das hat die Schaden-Kosten-Quote von 89,4 auf 86,7 Prozent verbessert. Ein Kriterium, das bei einer erfolgreichen Sanierung Alarm schlägt, misst das Falsche. Das echte Risiko ist die laufende Justizermittlung zur Medicare-Advantage-Abrechnung.
Erster Vollzug — die Sparpläne laufen seit dem 10.08.2026neu · umgesetzt
Mert hat beide ETF-Sparpläne bei Revolut eingerichtet und noch am selben Abend auf die offensive Fassung umgestellt: 80 EUR im Monat in den Welt-ETF (VWCE), 20 EUR in den Anleihen-ETF (AHYD, LU2439733507), Sparrate insgesamt 100 EUR. Beide provisionsfrei, beide ohne Verbrauch des Gratis-Handels. Damit ändert sich der Charakter des Projekts grundlegend: Der Kern des Depots wächst ab jetzt von selbst und braucht keine monatliche Kaufempfehlung mehr. Die Monatsentscheidung ist nicht länger "kauf diesen Titel", sondern "ändere die Sparplan-Raten auf X und Y" — und das auch nur, wenn die Rechnung eine Abweichung zeigt. Ein Monat ohne Empfehlung ist damit kein Ausfall mehr, sondern der Normalfall. Wichtig fürs Bauen: Die Sparpläne sind KEINE Empfehlung, die Mert ausführt, sondern ein Dauerauftrag, den DepotPi nicht sieht. Der Bestand muss deshalb zwingend gegen Revolut abgeglichen werden — DepotPi erfährt sonst nie, ob und wann die Käufe wirklich stattgefunden haben.
Gewichte werden nach MARKTWERT gerechnet, nicht nach Kaufpreisneu · Konstruktionsfehler
2026-08-10, aufgefallen beim Abgleich mit Merts echter Revolut-Depotansicht. InvestPis Leitplanken (pm_rules.weights) berechnen die Depot-Gewichte aus invested_eur — also aus dem, was die Position beim Kauf gekostet hat. Das ist falsch: Ein Depot-Gewicht ist ein Anteil am heutigen Vermögen, nicht an den Anschaffungskosten. Der Unterschied ist bereits real: ASML steht +31 Prozent, NVDA +18, UNH -2. Nach Kaufpreis gerechnet wirken alle fünf Positionen gleich groß (je rund 50 EUR), nach Marktwert reicht die Spanne von 48,14 bis 65,70 EUR. Genau darauf greift die 25-Prozent-Grenze für Einzelaktien zu — sie prüft also heute die falsche Zahl und lässt eine Position durchrutschen, die längst zu groß ist. Für DepotPi gilt: Zielaufteilung, Leitplanken und Rebalancing rechnen ausschließlich mit Marktwerten. Der Kaufpreis wird weiter gespeichert, aber nur für Gewinn/Verlust und Steuern, nie für Gewichte.
VWCE-Phantombuchung — der Bestand war doppelt falschneu · geklärt
2026-08-10, belegt durch Merts Revolut-Depotansicht. InvestPis config.yaml führte VWCE mit 0,608939 Stück und 100 EUR. Bei Revolut liegen 0,302188 Stück mit 50 EUR Einstand — also genau die Hälfte. Der VWCE-Kauf vom 01.08.2026 um 14:00 hat NIE stattgefunden; der alte Sparplan hat ihn automatisch verbucht, ohne dass eine Order ausgeführt wurde. Damit waren am 1. August BEIDE Buchungen falsch, und zwar in entgegengesetzte Richtungen: VWCE wurde gebucht, aber nicht gekauft (50 EUR zu viel), UNH wurde gekauft, aber nicht gebucht (50 EUR zu wenig). In der Summe hoben sich die Fehler fast auf — weshalb niemandem etwas auffiel. Das ist der schlimmste Fall: Ein Buchhaltungsfehler, der sich selbst tarnt. Lehre für den Neubau, über die schon beschlossene Datenbank-Lösung hinaus: Der Bestand muss regelmäßig gegen die Wirklichkeit abgeglichen werden. Eine Buchung, die niemand gegen den Broker prüft, ist eine Behauptung. Merts Revolut-Umsatzliste ist die Wahrheit, DepotPis Datenbank nur eine Kopie davon.
KERN-RANDBEDINGUNG WIDERLEGT — ETF-Sparpläne bei Revolut sind freineu · wichtig
2026-08-10, belegt durch Merts Screenshots aus der Revolut-App plus Nachrecherche. Das ganze Projekt stand seit dem 01.08.2026 auf dem Satz "Revolut gibt EINEN Gratis-Handel pro Monat, jeder weitere kostet bis zu 2 Prozent". Für ETFs stimmt das nicht. Revolut hat gebührenfreie ETF-Sparpläne: über 300 in der EU gelistete ETFs, ab 1 Euro, wöchentlich oder monatlich — provisionsfrei UND ausdrücklich NICHT gegen das monatliche Gratis-Kontingent gezählt. Die Käufe bleiben auch dann kostenlos, wenn das Kontingent längst aufgebraucht ist. Folge: Für den Kern des Depots (Welt-Aktien, Anleihen) gibt es keine Handelsgrenze. Mehrere Anlageklassen können im selben Monat bespart werden, der Umbau in die Zielaufteilung geht damit schneller als gerechnet. Der Gratis-Handel wird nur noch für zwei Dinge gebraucht: Einzelaktien (die Satelliten) und Verkäufe. Offen ist, ob Gold sparplanfähig ist — Gold-Papiere sind technisch keine Fonds, sondern Schuldverschreibungen, und das Sparplan-Angebot nennt ausdrücklich ETFs. WICHTIG, damit daraus kein Schaden wird: Die Kostenbremse war nicht nur eine Last, sie war auch ein Schutz vor Aktionismus. Dass Handeln jetzt gratis ist, ist KEIN Grund, öfter zu handeln — die Morningstar-Zahlen zum Anlegerverhalten gelten unverändert. Die Beschränkung auf wenige, begründete Entscheidungen bleibt, ab jetzt als bewusste Regel statt als erzwungene Grenze.
Der Gratis-Handel-Zyklus läuft NICHT ab dem Monatserstenneu
2026-08-10, aus Merts Screenshot: "Du hast alle deine kommissionsfreien Trades aufgebraucht. Dein Limit wird am 26. Aug. zurückgesetzt." Der Zähler ist ein rollierendes Monatsfenster ab dem 26., nicht ab dem 1. Der bestehende Monats-Job läuft aber am 1. um 14:00 und nimmt an, dass dann ein frischer Gratis-Handel bereitsteht. Das ist falsch: Am 1. läuft das Fenster bereits seit sechs Tagen. Belegt ist das auch am aktuellen Stand — Mert hat heute 0 freie Handel übrig. Für DepotPi heißt das: Der Zähler in pm_rules (ein Handel je Kalendermonat) bildet die Wirklichkeit nicht ab und muss beim Neubau auf das echte Fenster umgestellt werden — oder er verliert seine Bedeutung, weil der Kern ohnehin über Sparpläne läuft.
Zielaufteilung festgelegt — 55 Welt-Aktien / 20 Einzelaktien / 15 Anleihen / 10 Goldneu
2026-08-10. Merts Rahmendaten, von ihm selbst genannt: Notgroschen für mehrere Monatsausgaben liegt AUSSERHALB des Depots. Zeithorizont gemischt — ein Teil wird voraussichtlich in 5 bis 10 Jahren entnommen, um anderswo investiert zu werden, sicher ist das aber nicht. Und: Mert hat ausdrücklich gesagt, dass er den Empfehlungen folgt, statt eigene Anlagemeinungen zu bilden. Daraus folgt die Aufteilung. Der Notgroschen ist der wichtigste Schutz überhaupt: Mert MUSS im Crash nicht verkaufen, das erlaubt 75 Prozent Aktienanteil. Dagegen steht das 5-bis-10-Jahre-Fenster — deshalb keine höhere Aktienquote. Der Anleihen- und Gold-Teil ist ausdrücklich KEINE Renditebremse, sondern der Entnahme-Topf: Wenn Mert in einigen Jahren etwas herausnimmt, nimmt er es aus dem Teil, der gerade nicht im Minus steht, statt Aktien im Tief zu verkaufen. Dritter Faktor, der die Aufteilung vorsichtiger macht statt offensiver: Wer blind folgt, hat keine zweite Instanz, die einen Fehler des Systems abfängt. Weniger Spielraum ist hier die richtige Antwort, nicht mehr.
Neufassung vorgeschlagen — DepotPi wird Risiko-Verwalter statt Aktien-Sucherwartet auf Mert
2026-08-10 (DepotPi-Instanz, auf Merts Auftrag "denk das von Grund auf neu"). Belege in der Ansicht "Neufassung". Kern: Bei 252 EUR Depot und 50 EUR Sparrate entscheidet die Aufteilung über Anlageklassen das Ergebnis, nicht die Titelauswahl — in einem typischen Portfolio stammen rund 97 Prozent des Risikos aus der Klassen-Aufteilung. Die Monatsentscheidung wird damit zu reinem Code (welche Klasse liegt am weitesten unter Ziel, dorthin die 50 EUR), das Sprachmodell urteilt nur noch über Gleichlauf, Thesen und ob die Zielaufteilung selbst noch passt. Diese Entscheidung ist NOCH NICHT getroffen — sie hängt an Merts Antwort zur Schwankungstoleranz.
Das Warnsystem aus InvestPi kommt nicht mit — nachgemessen, nicht vermutetneu
2026-08-10. Der Risiko-Bewerter (risk_scorer.py, 78 KB, 9 Dimensionen, Finnhub-Abo) hat sich selbst protokolliert, also wurde er an 18.000 ausgewerteten Vorhersagen nachgerechnet. Ergebnis: Basisrate für einen Einbruch über 8 Prozent liegt bei 3,4 Prozent. Nach Alarmstufe 1 trat er in 1,7 Prozent der Fälle ein (seltener als ohne Warnung), nach Stufe 2 in 5,7 Prozent — und der Kurs stieg danach im Schnitt trotzdem um 2,5 Prozent. Nur Stufe 3 trägt echte Information (31,5 Prozent Einbruchsrate, negative Folgerendite), feuerte aber nur 54 mal in rund 56.000 Läufen. Für ein Depot aus Indexfonds sind zudem 6 der 9 Dimensionen gar nicht anwendbar (Insider-Geschäfte gibt es bei einem Welt-ETF nicht). Konsequenz: fällt weg, samt Momentum-Scan, Nachrichten-Stimmung, Quartalsterminen, Marktbreite und Konjunkturdaten.
Trendfolge (200-Tage-Linie) wird bewusst NICHT gebautneu
2026-08-10. Der Ansatz ist gut belegt (Faber 2007 senkte den maximalen Verlust um rund 80 Prozent, hielt sich auch außerhalb des Untersuchungszeitraums). Trotzdem verworfen, aus drei Gründen: Jeder Ausstieg verbraucht den Gratis-Handel des Monats, bei Seitwärtsmärkten frisst das Hin und Her die Sparrate. Verlustbegrenzung ist ein Bedürfnis von Leuten, die vom Depot leben — bei 252 EUR und Jahrzehnten Horizont ist ein Absturz die günstigste Kaufgelegenheit. Und es bleibt Markt-Timing mit einer schöneren Begründung. Kann später kostenlos parallel mitgerechnet statt gehandelt werden, wenn die Frage wieder aufkommt.
Der Depot-Bestand kommt in eine Datenbank, nicht in eine Git-Dateineu
2026-08-10 (DepotPi-Instanz, nach der Bestandsaufnahme). Bei InvestPi steht der echte Depot-Bestand in der config.yaml — einer Datei im Git-Repo, das alle zwei Minuten hart zurückgesetzt wird. Am 01.08.2026 hat genau das eine reale Buchung vernichtet (siehe Befund 1). Der Bestand ist kein Quelltext und keine Einstellung, sondern ein Kontostand: er gehört in eine SQLite-Datenbank außerhalb des Repos, die nur DepotPi schreibt. Ein Kontostand, den ein Deploy-Mechanismus überschreiben kann, ist kein Kontostand.
DepotPi wird ein eigenes Projekt — abgespalten von InvestPineu
2026-08-10 (Mert). Der monatliche Portfolio-Manager war in InvestPi ein Fremdkörper. InvestPi handelt Momentum auf einem Papier-Konto, vollautomatisch, stündlich. DepotPi verwaltet echtes Geld mit genau einem Handel im Monat und einem Menschen, der jede Aktion selbst ausführt. Zwei gegensätzliche Logiken, die sich Datenbank, Telegram-Bot und Konfiguration teilten — jede Änderung am einen konnte das andere treffen. Ab jetzt getrennt: eigener Ordner, eigener Nutzer, eigene Session, eigener Chat.
Eigener Systemnutzer statt Ordner unter pineu
2026-08-10. Hier hängt echtes Geld dran, dazu Telegram-Zugang und KI-Schlüssel. Nach der Pi-Konvention bekommen Geld- und Secret-Projekte einen eigenen abgeschotteten Nutzer (wie InvestPi). Uebergangsweise ist depotpi in der Gruppe investpi, damit der Umzug die alten Dateien überhaupt lesen kann — dieses Leserecht wird nach Phase 1 wieder entzogen.
Umzug erst, Abschaltung später — kein Big Bangneu
2026-08-10. Der Monats-Job läuft am 1. mit echtem Geld dahinter. Ein halbfertiger Umzug, der am 1. September ins Leere läuft, kostet einen Monat Depot-Verwaltung. Deshalb: InvestPi bleibt scharf, bis DepotPi nachweislich dasselbe liefert. Nächster Ernstfall ist der 01.09.2026 — bis dahin ist Zeit, aber nicht beliebig viel.
EIN Handel pro Monat ist die Kern-Randbedingung (übernommen aus InvestPi)bestand
Von Mert am 2026-08-01 gesetzt, hier unverändert weitergeführt. Revolut gibt einen Gratis-Handel pro Monat; bei 50 EUR Rate kostet jeder weitere bis zu 2 Prozent. Jede Idee, die mehr als einen Handel pro Monat braucht, ist damit erledigt — egal wie gut sie klingt. Offener Punkt: was ein zweiter Handel in Merts Tarif WIRKLICH kostet, ist noch nicht nachgeschaut (siehe Aufgaben).
Kein Kurs-Orakel — der Job ist Depot-Verwaltungbestand
Uebernommen aus InvestPi (Backtests 2026-06). Der Versuch, per KI vorherzusagen welche Aktie nächsten Monat steigt, wurde in den eigenen Backtests sauber widerlegt. Was das Sprachmodell dagegen kann: beurteilen, ob der Grund für eine gehaltene Position noch gilt. Darauf ist DepotPi gebaut — Thesen und ihre Widerlegung, nicht Prognosen.
Offene Aufgaben für Mert
- Revolut-Gebühr für den zweiten Handel nachschauen einmalig — Wenn du mal in der Revolut-App bist: nachschauen, was ein Handel über dein Gratis-Kontingent hinaus kostet.
- Notion-Projektseite für DepotPi anlegen einmalig — Kurz freigeben, dann lege ich DepotPi in deiner Notion-Projektdatenbank an.
- Depot-Aenderungen melden, wenn du selbst kaufst oder verkaufst routine — Selbst bei Revolut gekauft oder verkauft? Der DepotPi-Session sagen, sonst rechnet sie mit einem falschen Depot.
Notizen
Drei Warnungen für jede Instanz, die hier arbeitet. Erstens: Hier hängt echtes Geld dran. Kein Job wird bei InvestPi abgeschaltet, bevor das Gegenstück hier nachweislich dasselbe liefert — ein übersprungener Monat ist ein realer Verlust, kein Testfehler. Zweitens: InvestPis Manifest und Code liegen im Git und werden alle zwei Minuten per Auto-Pull hart zurückgesetzt. Änderungen dort überleben das nicht, wenn sie nicht ins Repo committet sind — wer beim Umzug in InvestPi etwas anfasst, muss das wissen. Drittens, und das ist die Lehre aus Befund 1: Der Depot-Bestand darf bei DepotPi NICHT in einer Datei liegen, die von einem Auto-Pull überschrieben werden kann. Er gehört in eine Datenbank außerhalb des Git-Repos. Genau dieser Fehler hat bei InvestPi eine reale Buchung gekostet.
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 während 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 während 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 prüft 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)
Wochen-Review (Live vs. Backtest)neu
weekly_review.py — hält Live ehrlich gegen die Backtest-Erwartung (Edge da/nicht da/Rauschen), read-only. Kein Auto-Tuning (InvestPi-Lektion) — Änderungen nur nach OOS-Beweis durch Mensch.
Attribution (P/L-Aufschluesselung)fertig
attribution.py — schluesselt P/L nach Richtung, Ausstiegsgrund (Stop/Ziel/Zeit), rel-Volumen, Symbol-Typ, Uhrzeit, Slippage auf. Read-only. Erster Befund siehe Entscheidungs-Log.
Backtest-Gate (auto)offen
Strategie-Änderungen automatisch erst nach OOS-Bestaetigung zulassen
✅ 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
Abbruch-Maßstab (2026-08-18): woran DayPi stirbt — vorab festgelegt2026-08-18
Von Mert am 18.08.2026 beauftragt und abgenickt. Gegenstück zur Go-Live-Latte: Die Bedingungen, unter denen DayPi eingestellt wird, stehen fest, BEVOR Geld (99 $/Monat SIP-Feed) und Arbeit hineinfließen — weil man diese Entscheidung später, mitten in einer Verlustserie oder nach investierter Mühe, nicht mehr ehrlich trifft. ABGESCHALTET WIRD, sobald EINES davon eintritt: (1) NEGATIV-BEWEIS: Schnitt-R statistisch unter null, t <= -2 über >= 400 abgeschlossene Live-Paper-Trades — exaktes Spiegelbild der Go-Live-Latte (t >= +2). (2) RÜCKSCHLAG-BRUCH: intraday gemessener Rückschlag <= -20% seit Start, bei 0,6% Risiko/Trade. Die Erwartung aus dem 365-Tage-Test (auf 0,6% skaliert) liegt bei rund -9% bis -10%; -20% ist damit klar außerhalb der Eigenstreuung und heißt: das Modell der Strategie stimmt nicht. (3) DATEN-DECKEL: falls der bezahlte SIP-Feed je gebucht wird, läuft er befristet auf 3 Monate. Bringt er in dieser Zeit keinen messbaren Fortschritt Richtung 400 Trades bei unverändertem oder besserem Schnitt-R, wird gekündigt und auf IEX zurückgestellt — kein stilles Weiterlaufen des Abos. (4) BETRIEBS-TOD: wenn DayPi über 3 Monate nicht mehr sauber handeln kann (Feed, Infrastruktur, Broker) und die Reparatur mehr als einen Nachmittag kostet. WAS AUSDRÜCKLICH KEIN ABBRUCHGRUND IST: einzelne schlechte Wochen, Verlustserien, ein negatives Quartal, Bauchgefühl, Langeweile, ein spannenderes Projekt. Genau daran scheitern die 97% der Daytrader — nicht am Modell, sondern am Drehen an Schrauben nach Pech. Solange keiner der vier Punkte erfüllt ist, läuft DayPi unverändert weiter; das Urteil fällt die Statistik, nicht die Stimmung. WARUM ÜBERHAUPT WEITERLAUFEN: Der Betrieb kostet fast nichts (Paper-Konto, Gratis-Feed, der Pi läuft ohnehin). Die Chance auf eine echte Edge ist klein (Größenordnung 10-15%), aber nicht null — fällt sie positiv aus, sind das bei +0,04R und ~625 Trades/Jahr grob +25% p.a. Der eigentliche Wert des Projekts liegt im belastbaren Nein, das man sich hier leisten kann.
Varianten-Gegencheck (2026-08-09): alle drei Live-Verdachtsmomente WIDERLEGTwiderlegt
2026-08-09. Die Live-Auswertung (108 Trades) legte drei Reparaturen nahe. Alle drei wurden mit ``scripts/variant_test.py`` gegengeprueft (365 Tage, Train/OOS-Split, ZWEI Feeds als quasi unabhaengige Stichproben — IEX und SIP ueberlappen laut iex_backtest.py nur ~10%). Ergebnis: (1) SHORT-SEITE ABSCHALTEN ist falsch. OOS beide Seiten +0,126R (IEX) / +0,127R (SIP); nur Long +0,042R / +0,054R; nur Short +0,036R / +0,046R. Über das Gesamtjahr auf IEX ist Short sogar die BESSERE Seite (+0,046R vs +0,036R). Mechanik: der Bot nimmt täglich die Top-3 nach rel. Volumen — verbietet man eine Seite, ruecken schwaechere Kandidaten nach (n faellt nur 220->180, nicht auf die Haelfte). Der FILTER ist die Edge, jede Seiten-Einschraenkung verwaessert ihn. Die -8.704 $ der Live-Shorts sind ein Pech-Lauf über 49 Trades. (2) EINSTIEGSFENSTER kuerzen bringt nichts: das Fenster 10:00-11:30 ist OOS zwar negativ (-0,025R IEX / -0,081R SIP), aber nur ~15% der Trades; schneidet man es weg, wird IEX minimal besser (+0,129) und SIP SCHLECHTER (+0,120). Im Trainings-zeitraum war dasselbe Fenster auf SIP sogar +0,112R. = Rauschen. (3) MEHR TRADES (Top-N hoch) ist teuer erkauft: OOS Top-3 +0,126R -> Top-5 +0,077 -> Top-8 +0,075 -> Top-12 +0,050 (IEX; SIP gleiche Richtung), während der größte Rueckschlag von -15,9% auf -33,5% steigt. Jeder zusaetzliche Trade pro Tag ist ein schlechterer Trade; der Beweis wird dadurch NICHT schneller. FAZIT: an der Strategie ist nichts offensichtlich kaputt, und Regel #1 (nicht spontan nachtunen) hat vor drei falschen Reparaturen bewahrt. config.yaml in allen drei Punkten UNVERAENDERT.
Risiko je Trade 1,0% -> 0,6% gesenkt (2026-08-09) — das 12%-Gate war unerreichbargeändert
2026-08-09. Befund aus demselben Lauf: die UNVERAENDERTE Live-Strategie erzeugt bei 1,0% Risiko/Trade über 365 Tage einen groessten Rueckschlag von -16,7% (IEX) / -14,7% (SIP) — strukturell über der 12%-Notbremse des Echtgeld-Maszstabs. Live standen wir am 27.07. bereits bei -10,85% (intraday). Das Gate war auf der SIP-Illusion kalibriert (-8% Backtest-DD) — derselben Illusion wie die +30%-Rendite. Ein Gate, das die Strategie im NORMALBETRIEB reiszt, haette das Experiment aus einem Nicht-Grund beendet. Gemessene Alternativen: 0,8% -> -13,5% | 0,7% -> -11,9% (kein Puffer) | 0,6% -> -10,3% (IEX) / -9,0% (SIP). GEWÄHLT: 0,6%. Bewusst NICHT das Gate aufgeweicht (Regel #2 verbietet Lockern; Mert hatte die 12% ausdruecklich als nicht-verhandelbar abgenickt) — stattdessen das Risiko so weit gesenkt, dass die Latte einhaltbar wird. Kostet KEINE Messqualitaet: die R-Vielfachen je Trade sind unveraendert, nur die $-Skala schrumpft. CAVEAT, offen für Widerspruch: die DD-Messung für den Echtgeld-Maszstab startet mit der Umstellung neu; die alten -10,85% stammen aus der zu grossen Positionsgroesse und bleiben hier dokumentiert, statt still zu verschwinden.
Backtest-Erwartung ist eine SPANNE (+0,03 .. +0,13R), keine Zahl (2026-08-09)korrigiert
2026-08-09. Der Wert ``+0,039R als realistische IEX-Decke`` (Stand 14.07.) ist KEINE belastbare Messlatte. Derselbe Test, dieselbe Methode, nur das 365-Tage-Fenster um vier Wochen verschoben: OOS +0,029R / Sharpe 0,76 / maxDD -13,0% (Fenster bis 14.07.) gegen +0,128R / Sharpe 3,26 / maxDD -7,9% (bis 09.08.). Vierfacher Unterschied. Methode gegengeprueft: der neue Lauf reproduziert die Juli-Zahlen fast exakt (+0,029 vs +0,039 / maxDD -13,0% identisch), der Sprung kommt also allein vom Zeitfenster. Folge: die LIVE-Zahl (-0,047R über 108 Trades) liegt INNERHALB dessen, was derselbe Backtest als Eigenstreuung produziert — mit den vorhandenen Daten lässt sich schlicht nicht sagen, ob die Strategie funktioniert. ``weekly_review.py`` rechnet ab jetzt mit der Spanne (EXP_AVG_R_RANGE) statt mit einer Punktschaetzung und nennt die Beweisdauer als Spanne: bei einem wahren Vorteil von +0,13R braucht es ~250 Trades (~0,4 Jahre), bei +0,08R ~650 (~1,2 Jahre), bei +0,03R ~4.600 (~8 Jahre). R-Streuung gemessen: sd = 1,02.
Go/No-Go-Termin ``Ende August bei 150 Trades`` gestrichen — ersetzt durch Abbruch-Regelersetzt
2026-08-09. Der Termin war konstruktionsbedingt sinnlos: der Maszstab verlangt >=150 Trades UND Schnitt-R statistisch über null (t>2). Bei sd=1,02 und einem Vorteil in der Größenordnung +0,08R braucht t>2 rund 650 Trades — bei 150 ist ein ``Ja`` mathematisch unmöglich. Der Termin konnte also nur ``Nein`` oder ``weiter sammeln`` ergeben und haette bei schlechter Laune leicht zum vorzeitigen Einstampfen einer funktionierenden Strategie gefuehrt. NEU (gilt ab sofort): DayPi läuft ohne Ablaufdatum weiter — Betriebskosten sind praktisch null. Gestoppt wird nur bei einem ECHTEN Negativ-Beweis, nicht nach Kalender: (a) ABBRUCH, wenn der kumulierte Schnitt-R statistisch signifikant NEGATIV ist (t <= -2) — das kann frueh und ehrlich ausloesen; (b) ABBRUCH, wenn der größte Rueckschlag ab der 0,6%-Umstellung -12% reiszt; (c) die Echtgeld-FRAGE wird überhaupt erst gestellt, wenn t >= +2 über >=400 Trades erreicht ist. Erwartete Wartezeit ehrlich: ein bis mehrere Jahre, je nachdem wie gross der Vorteil wirklich ist. Statt eines Einmal-Urteils gilt die laufende Quartals-Bewertung.
Gesamt-Zeitverlauf in der Datenbrücke (2026-07-29): Tagesschluss-Historie statt nur Heute
2026-07-29. Der DayPi-Tab der InvestPi-Webapp kannte bisher nur ``equity_curve`` = den heutigen Intraday-Verlauf; jede Nacht war die Kurve wieder weg, ein Gesamtbild seit Start gab es nirgends. ``snapshot.py`` schreibt jetzt zusätzlich ``equity_history`` (letzte Equity je Handelstag seit 2026-06-16, mit vorgerechnetem ``pl_pct`` gegen die 100k-Startlinie und ``dd_pct`` = Abstand zum bisherigen Hoch) plus ``history_days``, ``peak_equity_usd``, ``max_drawdown_pct``. Bewusst so: (a) ein Punkt je TAG, nicht je Minute — die Datei bleibt auch nach Jahren klein (30 Tage ≈ 3 KB); (b) Prozente/Drawdown rechnet DayPi, nicht die Webapp — nur EINE Stelle kann falsch rechnen; (c) Lücken an Wochenenden/Feiertagen bleiben drin, die Webapp zeichnet als Kategorie-Achse. ARBEITSTEILUNG: Die Webapp liegt beim Nutzer investpi, DayPi kommt da nicht ran (kein Lese-/ Schreibzugriff) — DayPi liefert nur die Daten, gezeichnet wird der Chart von der InvestPi-Instanz. Feld-Doku für die andere Instanz: ``docs/webapp-datenbruecke.md`` (welt-lesbar).
Live-Verlust-Diagnose (2026-07-14): Gratis-Feed HALBIERT die Edge + handelt ein anderes Buch — Backtest-+30% war Illusion
2026-07-14. Nach ~4 Wochen Live-Forward-Test harter Widerspruch: SIP-Backtest (365T, Live-Config) OOS +0.095R / 54% Win / Sharpe 2.5 / +30.6% — LIVE seit eval_start 2026-06-18 aber -0.12R, 40% Win, -8.207$ (Equity 100k -> ~91.9k) über 68 Trades. Attribution: der GESAMTE Verlust sitzt in Stop-Exits (24 Stops -17.5k$; Ziel+Zeit-Flat zusammen +8.6k$). DREI Tests gefahren (alle read-only, config UNVERAENDERT, Regel #1): (1) stop_check.py (OOS 70/30): enger 0,5x-ATR-Stop ist OOS der BESTE, weitere Stops schlechter -> Stop WIDERLEGT als Ursache. (2) feed_gap_check.py (SIP vs IEX frisch, umgeht den NICHT feed-getrennten Pickle- Cache!): 0% leere IEX-Fenster, OR-Level nur ~5bps ab -> grober Feed-Ausfall ausgeschlossen; ABER IEX sieht nur 2% der Tape. (3) iex_backtest.py (volle Live-Strategie EINMAL auf frischem SIP, EINMAL auf frischem IEX, gleiche OOS-Auswertung): SIP OOS +0.095R/54%/Sharpe2.5 vs IEX OOS +0.039R/47%/Sharpe1.03/maxDD-13%. KERNBEFUND Auswahl-Treue: SIP wählt 622 Trades, IEX 723, nur 62 GEMEINSAM = ~10% Ueberlappung -> der rel-Vol-Filter selektiert auf 2% Tape ein FAST ANDERES Buch. FAZIT: Der Gratis-IEX-Feed halbiert den Edge (0.095->0.039R) und ändert WELCHE Trades genommen werden; die Backtest-+30% waren nie für uns erreichbar (falscher Feed). Realistische Decke am Gratis-Feed = duenn (Sharpe~1). Rest-Luecke IEX-Backtest +0.039R vs live -0.12R ist NICHT Feed (beide IEX) sondern Stichprobe (z=-1,3) + Live-Reibung (echte Fills, dynam. Universum, Timing). EINORDNUNG: aktuell KEIN glaubwuerdiger Echtgeld-Pfad — Latte runter von "+30%" auf "bestenfalls duenn positiv, noch unbewiesen". FORK offen (Mert): (a) bezahlter SIP-Live-Feed (Kosten, +Neu-Beweis noetig) vs (b) Gratis bleiben + Erwartung=+0.039R + Go/No-Go-Checkpoint vs (c) Strategie als marginal einstufen. Neue Werkzeuge: scripts/feed_gap_check.py, scripts/iex_backtest.py. CAVEAT: 10%-Overlap leicht ueberzeichnet (Fingerprint nutzt Entry-Preis auf 2 Nachkommastellen; leicht andere OR-Trigger zählen als "anderer" Trade) — Richtung aber eindeutig (Trade-Zahlen 622 vs 723 + Win 54% vs 47% divergieren real).
Bug-Audit (Opus + Fable-5-Gegencheck) — 3 aktive Track-Record-Vergifter gefixt, HIGHs offen
2026-07-02. Voller Korrektheits-/Risiko-Review der Live-Handels- und Abrechnungslogik: erst Opus, dann ein unabhaengiger Fable-5-Unteragent als adversariale Gegenprobe (frisch, ohne meine Funde vorzusagen). Fable bestaetigte alle Opus-Funde UND legte mehrere echte drauf, inkl. gegen den echten DB-/systemd-Stand verifiziert — fuers Bug-Finden hat sich das Top-Modell hier gelohnt (als Dauer-Standard weiterhin nicht, 2x Preis). SOFORT GEFIXT (alle: reine Datenhygiene bzw. Ruecksetzen auf die validierte Strategie, kein neuer Edge -> Regel #1 unberuehrt): (#4) Live handelte bis zu 9 Namen/Tag (Watchlist- Größe), validiert (backtest.py [:top_n]) sind aber TOP 3 — passierte schon real (bis 7 Trades/Tag) und verfaelschte den Track-Record; Entry-Abfrage jetzt ORDER BY rel_volume DESC LIMIT top_n. (#8) settle rechnete R/return mit BESTELLTER statt gefuellter Menge -> bei Teilfuellung still zu kleine Kennzahlen; nutzt jetzt die real gefuellte Entry-Menge (buy_qty/sell_qty aus den Fills). (#9) daily_atr enthielt die heutige, unfertige Tageskerze -> ATR gedrueckt -> Positionen ~7% zu gross jeden Tag; heutige Bar wird jetzt vor der TR-Rechnung gedroppt. RUNDE 2 GEFIXT (2026-07-02, die drei HIGHs — alle Risiko-Klempnerei, kein OOS noetig): (#1) Flat-before-Close war hart 16:00 -> an Halbtags-Boersentagen (2026: 27.11.+24.12., Close 13:00) feuerte es nie -> Overnight-Risiko; jetzt aus clk.next_close abgeleitet + Overnight-Alarm ins ERROR_LOG, wenn Markt zu und noch Positionen offen. (#2) Order-Submit lief VOR dem DB-Commit (einziger Commit am Schleifenende) -> Crash/SIGTERM dazwischen = Doppel-Order + settle zaehlte P/L doppelt; jetzt trades-Zeile ZUERST als pending committen, submitten, auf submitted updaten (Fehler -> pending löschen), plus client_order_id=orb-<sym>-<tag> als Alpaca-Idempotenz-Key. (#3) unbefuellte Entry-Limits wurden nie gecancelt und zaehlten nicht in open_count/gross_notional -> konnten Positions-+Hebel-Cap umgehen und später adversariell fuellen; jetzt pro Tick a.open_orders(): junge pending-Limits zählen in die Caps, veraltete (>entry_stale_sec=120s ODER nach Cutoff) werden gecancelt. Verifiziert: kompiliert, Dry-Run ok, client_order_id/next_close/open_orders per Read-Call gegen Alpaca bestaetigt; die volle Handelslogik läuft erstmals am nächsten Markt-offen-Tick scharf. NOCH OFFEN (MEDIUM/LOW, unkritisch): Daily-Loss ohne Tages-Latch (#5), Flatten hängt an 1 Pi-Tick ohne Echtzeit-Alarm (#6), OR-Levels evtl. aus unvollstaendigem Fenster (#7), settle nur für heute -> Ausfalltag nie nachgerechnet (#10), TimeoutStartSec=90 zu knapp (#11), Not-Aus/Pfade am fremden /home/pi-Symlink (#12), plus LOW #13-15.
Phantom-Quote-Filter + Stop-Geometrie-Waechter + Digest-Median — 3 Fixes nach SHOP-Analyse
2026-07-01. Der Monats-Digest zeigte Entry-Slippage O -56,8 bps (alarmierend), worst SHOP -674 bps. Detail-Analyse ergab: SHOP war KEIN teurer Fill, sondern ein Feed-Glitch — IEX meldete einen Mid von 118,84 (real handelte SHOP ~111, OR-High 111,41, Fill 110,83) mit ENGEM Spread, also am Spread-Check (max_quote_spread_bps) vorbei. Der Phantom-Preis vergiftete Stop/Target: Long-Stop 116,22 lag ÜBER dem echten Fill -> Position flog quasi sofort flat raus (Schaden nur -51,5$, aber latent gefaehrlich: Phantom in Gegenrichtung = viel zu weiter Stop = ueberdimensionierte Risiko-Position). CBRS 24.06. derselbe Typ (Mid 213,5 vs real ~199,6). WICHTIG: der echte Ausfuehrungs-Median liegt bei -1,2 bps = Fills sind normal SAUBER; die -56,8 bps Mittelwert wurden von 2 Glitches gekapert. Drei Fixes (rein Datenhygiene/Risiko-Klempnerei, KEINE Strategie-Änderung -> Regel #1 unberuehrt, kein OOS noetig): (1) PHANTOM-FILTER in daypi_live: Quote-Mid gegen letzten ECHTEN Trade-Preis (a.latest_trade, neu im alpaca_client) — |Mid-LastTrade| > max_quote_vs_trade_bps (150) ODER Trade fehlt -> kein Entry. Faengt "eng aber stale", was der Spread-Check durchliess (SHOP 722 / CBRS 697 bps gegengeprueft, saubere Namen <10 bps). (2) STOP-GEOMETRIE-WAECHTER: vor Orderabgabe prüfen Long stop<entry<target bzw. Short target<entry<stop; Verletzung -> verwerfen + als skip loggen (Defense-in-Depth gegen invertierte Levels). (3) DIGEST zeigt jetzt Median (ehrliches Mass) neben Mittelwert und flaggt Ausreisser >|150| bps separat als wahrscheinliche Feed-Glitches, damit ein paar Glitches die real gesunde Ausführung nicht mehr maskieren. CAVEAT: der 150-bps-Cap könnte in den hektischen Eroeffnungsminuten selten einen legitimen schnellen Breakout skippen (sichere Richtung: lieber Trade verpassen als Phantom nehmen) — via session_check auf Über-Filterung beobachten, Cap ist konfigurierbar.
Slippage-Alarm in R statt flacher bps — Fehlalarme auf guenstigen Fills abgestellt
2026-06-30. Der Session-Check (Punkt 4) urteilte Slippage früher gegen eine starre 50-bps-Linie in BEIDE Richtungen (Stand 24.06.) und feuerte Telegram. Folge: am 29.06. Fehlalarm auf RIOT (-53,7 bps = -0,15R) — dem BESTEN Trade des Tages (+1.509$, +1,65R, ein Short, der höher verkaufte als geplant = guenstig, kein Verlust). Umbau: (1) Urteil in R, nicht bps — was die Edge frisst, ist Slippage relativ zum Trade-Risiko; auf einem 7%/Tag-Mover ist 0,5% Drift Rauschen. Echte-Kosten-ALARM erst bei >0,5R einzeln oder >0,25R im Schnitt. (2) Ein guenstiger (negativer) Fill ist NIE ein Telegram-Alarm. (3) Extrem guenstige Ausreisser (>300 bps, z.B. SHOP 24.06. -674 bps = kaputter stale IEX-Quote) bekommen nur einen leisen "HINWEIS" im Bericht — bewusst OHNE das Wort "ALARM", damit run_session_check.sh kein Telegram ausloest. Verifiziert gegen 3 historische Tage: 29.06 RIOT -0,15R -> OK/kein Ping; 24.06 SHOP -3,06R guenstig -> HINWEIS/kein Ping; 22.06 RGNX +0,97R echte Kosten -> ALARM/Ping bleibt. Zweck: nicht "Bauer ruft Wolf" — Mert nur bei echten Problemen wecken.
Benachrichtigung: Telegram NUR bei ALARM + monatlicher Digest (read-only)2026-06-25
2026-06-25, auf Merts Wunsch. Tagesbericht NICHT mehr per Telegram (er schaut aktiv in die Webapp); Telegram nur noch als Feuermelder, wenn session_check ALARM meldet (run_session_check.sh grept den Bericht auf "ALARM" und schickt die Alarm-Zeilen). Stiller Tag = keine Nachricht. Dazu ein monatlicher Digest (monthly_digest.py, Vorbild InvestPi-Monatsdigest): read-only, 1. des Monats 09:00 für den Vormonat, deckt Ergebnis/Ausfuehrungs-Qualitaet (Slippage, Fill-Quote, Quote-Skips)/ehrliches Edge-Urteil/Fortschritt Richtung 150-Trades-Gate ab, geht 1x/Monat per Telegram raus. Gemeinsamer Sender telegram_alert.py liest .telegram.env (daypi-lesbar, 600, via *.env in .gitignore). Architektur: bewusst KEIN root-Relay (alter Ansatz verworfen) — die 2 Telegram-Werte werden einmalig aus dem System-Bot in eine daypi-Datei kopiert, dann läuft alles im bestehenden daypi-Cron, ohne root-Timing. Secret-Abwaegung: Telegram-Bot-Token ist geteilte Pi-Infra (kein Geld-Secret), 600-Kopie in daypi ok. Verifiziert: Alarm-Pfad baut korrekte Nachricht (gegen 24.6-Bericht), stiller Tag (25.6) schweigt, Digest für Juni läuft. CADENCE festgelegt: täglich passiv (Webapp/Alarm), wöchentlich Puls (Sa-Review), monatlich der Digest = der bewusste Hinschau-Moment. Erstes echtes Edge-Urteil fruehestens Ende Sept (3-Monats-Gate). NICHT vorher an Stellschrauben drehen.
Fill-Quoten-Messung gebaut — die fehlende 2. Hälfte der Echtgeld-Latte ist jetzt messbar2026-06-24
2026-06-24: Bisher war nur Slippage messbar; die Fill-Quote (fuellt das Deckel-Limit überhaupt, oder läuft der Kurs weg?) fehlte komplett — "submitted" hiess sowohl "gefuellt+offen" als auch "nie gefuellt". FIX: settle.reconcile_fills() gleicht jede Einstiegs-Order per order_id gegen Alpaca ab; nie gefuellte Limits -> trades.status=unfilled (idempotent, Wahrheitsquelle Alpaca-Order-Status). session_check Punkt 3 "FILL-QUOTE" zeigt gefuellt/gesamt + %, ALARM unter 50%, grenzwertig <70%. Zusätzlich: daypi_live loggt je Symbol/Tag (kein Tick-Spam) einen kind=skip-Eintrag, wenn der Quote-Guard eine Aktie wegen Muell-Quote ueberspringt -> session_check zeigt die Skip-Zahl = Fruehwarnung "reicht der Gratis-IEX-Feed?". Reine Messung, KEIN Eingriff in Handelslogik. Verifiziert am 24.6.: Fill-Quote 7/7 (100%), und SOFI lieferte mit sauberer Quote -8,2 bps Slippage (erster vernuenftiger einstelliger Messwert; CBRS/SHOP/DIS bleiben als kaputte Quoten geflaggt). BEOBACHTUNG (nicht angefasst, edge-relevant -> später mit OOS): eine nie gefuellte Order belegt aktuell trotzdem einen traded-Slot + zählt auf max_trades_per_day. Wenn die Fill-Quote dauerhaft niedrig ist, hier nachdenken.
FIX: Quote-Sanity-Guard gegen Müll-Quoten + Bericht flaggt Slippage in beide Richtungen2026-06-24
2026-06-24, behebt den Befund unten. URSACHE war: IEX-latest_quote liefert für manche Namen stale/halbseitige Quoten mit absurdem Spread (verifiziert via Alpaca-Orders: SHOP bid95,96/ask127,17 = 2797 bps; CBRS 416 bps; DIS 396 bps), während liquide Namen <10 bps liegen (GDX 1, TLT 1, SOFI 6, GLD 11). Der Bot nahm die Mid davon als Preis -> Entry-Entscheidung, Stop/Target, Sizing UND Slippage-Messung alle vergiftet. FIX 1 (daypi_live.py, risikoSENKEND, kein Edge-Eingriff): vor jedem Entry Quote-Sanity — fehlt/gekreuzt ODER Spread > execution.max_quote_spread_bps (neu, =40) => SKIP, kein Handel auf Muell-Quote. Trennt sauber (liquide <10 bps passen, duenne 400-2800 bps fliegen raus); 40 bps ist auch oekonomisch der Deckel (ORB-Edge stirbt ~10-12 bps Einstiegskosten). FIX 2 (session_check.py, read-only): grosse Slippage in BEIDE Richtungen als Ausreisser/ALARM — stark NEGATIV ist kein Schnaeppchen, sondern ein kaputter Referenzpreis; Verdikt nutzt |bps|. Verifiziert: der heutige Tag wird jetzt korrekt als ALARM statt "OK" gemeldet, Guard skippt CBRS/SHOP/DIS und behaelt GDX/GLD/SOFI/TLT. Live ab naechstem Tick (Timer, kein Restart noetig). RESTRISIKO: Guard faengt NICHT "beide Seiten stale aber eng" (selten). Die heute schon gehandelten 24.6-Slippagewerte bleiben Muell (vor dem Fix entstanden) — nur kuenftige Sessions sind sauber. NICHT angefasst: Breakout-Logik, Stops, Sizing-Formel, Caps (kein Edge-Change -> keine OOS-Pflicht).
BEFUND: Slippage-Messung unzuverlässig — Referenzpreis vom IEX-Feed bei Open ist daneben (Mess-Gate noch NICHT bewertbar)2026-06-24
2026-06-24, erste Limit-Session (CBRS,SHOP,DIS,GLD,GDX,SOFI,TLT): session_check meldete Schnitt -538 bps Slippage (CBRS -651, SHOP -674, DIS -289) und stempelte trotzdem "OK, kein Handlungsbedarf". Beides falsch. URSACHE 1 (Referenzpreis): daypi_live.py Z.205-206 nimmt als "geplanten Preis" (trades.price) die Mid aus a.latest_quote() vom Gratis-IEX-Feed — und ALLE Entries feuern 09:35-09:41 ET, in den ersten chaotischen Minuten nach Open, wo IEX (dünn, ~2-3% Volumen) Quotes liefert, die 3-7% neben der Realität liegen. Beweis: CBRS geplant 213,52 / echter Fill 199,61; Round-Trip-P/L nur +0,08% -> echter Einstieg war ~199,6, die 213,52 ist Müll. Folge: das marketable Limit (Cap ±8 bps um price) UND Stop/Target/Sizing hängen alle an diesem schiefen Anker; die gemessene Slippage vergleicht den echten Fill gegen einen falschen Sollpreis = Rauschen. URSACHE 2 (Verdikt-Logik): session_check.py Z.97-112 alarmiert NUR bei positiver (Kosten-)Slippage > 50 bps; stark NEGATIVE Slippage (sieht aus wie "Bot kaufte 650 bps billiger") wird als Geschenk durchgewunken statt als kaputter Anker erkannt -> "OK". KONSEQUENZ: Das verfeinerte Mess-Gate aus dem Limit-Fix (realisierte Einstiegs-Slippage einstellig bps + Fill-Quote) ist mit den aktuellen Zahlen NICHT bewertbar — die Messung ist blind. Die echten Trades sind vermutlich ok (Round-Trips bewegten sich <0,2%), aber wir können die reale Slippage derzeit nicht messen. OFFEN/zu fixen (autonom, Paper): (a) belastbarer Referenzpreis für trades.price/Limit/Slippage statt roher IEX-Open-Quote (z.B. gegen Fill plausibilisieren / SIP-Historie / Open-Quote-Sanity), (b) session_check: große Slippage in BEIDE Richtungen flaggen, |bps| statt nur >0. Bis dahin: Slippage-Berichte NICHT für Edge-/Echtgeld-Urteil heranziehen.
Session-Check dauerhaft als täglicher Cron (löst Einmal-Job ab)2026-06-24
2026-06-24: run_session_check.sh (settle + session_check.py) jetzt Mo-Fr 22:45 lokal per crontab — kein selbstlöschender Einmal-Job mehr, der nach jeder Session von Hand neu scharfgestellt werden musste. Damit entsteht der lesbare Tagesbericht automatisch nach jeder Session (an handelsfreien Tagen sauberer No-Op). ACHTUNG: der Bericht ist aktuell nur halb vertrauenswürdig — Slippage-Teil unzuverlässig (siehe Befund-Card oben).
LIMIT-ORDER-FIX gebaut + live geschaltet (Cap 8 bps), NOT-AUS geloest -> kontrollierte Mess-Phase2026-06-24
2026-06-24: Wurzel war Market-Entry (daypi_live.py). FIX: Einstieg jetzt marketable Limit mit Deckel entry_cap_bps=8 (config.yaml execution-Block) — schlechterer Fill als 8 bps vom Mid => KEIN Fill (gewollt: kappt Blowup-Slippage, verpasst dafür den illiquiden Ausreisser). Backtest unberuehrt. OOS-Check scripts/limit_test.py (504T, 875 Trades, Exit-Slip konservativ 6 bps): Edge bleibt positiv bis ~10-12 bps Einstiegskosten (3bps +0,031R | 6bps +0,020R | 10bps +0,012R | 15bps -0,015R) -> 8 bps Cap lässt Marge. EHRLICHE GRENZE: das Minutenbar-Modell kann die VERPASST-Quote nicht messen (Spalte war strukturell 0) und sagt nichts über echte Live-Fill-Wahrscheinlichkeit. Darum: NOT-AUS (.KILL) geloest als KONTROLLIERTE MESS-PHASE — der einzige Weg, realisierte Live-Slippage + Fill-Quote zu messen (Backtest kann es prinzipiell nicht). Sicher, weil: Limit ist konstruktiv besser als das bewiesen-ruinoese Market, alle Risiko-Caps (Daily-Loss, Max-Pos, Flat-before-Close, Gross-Cap) bleiben scharf, Paper-Geld. Overnight-Risiko geprüft ausgeschlossen: close_all() im Flat-Fenster storniert offene Orders + DAY-TIF verfaellt abends. VERFEINERTES GATE (ersetzt "KILL bis OOS <6bps", was per Backtest unmöglich ist): Fix gilt als bestaetigt, wenn die LIVE-Paper-Messung (settle.py Entry-Slippage, session_check/weekly_review) realisierte Einstiegs-Slippage im einstelligen bps-Bereich UND eine brauchbare Fill-Quote zeigt. Bleibt die Slippage hoch ODER fuellt fast nichts -> ORB-auf-Stocks-in-Play ist für Echtgeld nicht tragfaehig, dann andere Edge. WATCH: erste Session(en) eng prüfen, bei mieser Slippage/Null-Fills sofort wieder .KILL.
KOSTEN-STRESS-TEST (504T OOS): Edge ist hauchduenn, stirbt bei ~6-7 bps -> live (56 bps) = sicherer Ruin. NOT-AUS gezogen.2026-06-24
2026-06-24: scripts/cost_stress.py über 2 Jahre, 875 gefilterte Trades, Slippage variiert. ERGEBNIS (Schnitt-R / Rendite / Sharpe): 3bps +0,043R/+38,6%/1,05 | 6bps +0,008R/+2,1%/0,19 | 15bps -0,098R/-59% | 30bps -0,273R/-91% | 56bps (LIVE) -0,577R/-99,2%/-11,7. KLARTEXT: die gesamte Edge passt in ~6 bps Kosten. Schon bei den von Regel #1 geforderten konservativen 6 bps ist die Strategie praktisch breakeven (Sharpe 0,19); ab ~7 bps sicherer Verlierer. Die +38,6% bei 3 bps waren immer Fiktion (genau wovor Regel #1 warnt). Live messen wir 56 bps (Market-Orders) -> die -5,5% der ersten Live-Woche sind KEIN Rauschen, sondern die mathematisch erwartete Ruin-Bahn. KONSEQUENZ (Leiter-Entscheidung, im Paper-Mandat): data/.KILL gesetzt -> keine neuen Entries mehr, Schutz-Exits laufen weiter. Begruendung: die Live-Config (Market-Entry) ist OOS BEWIESEN strukturell ruinoes; weiter handeln würde nur das saubere Eval-Fenster (ab 18.06.) mit bekannt-kaputten Daten zumuellen (CLAUDE.md: ein still kaputtes System untergraebt die Datenbasis). KILL bleibt, bis der Limit-Order-Fix OOS belegt unter ~6 bps Live-Slippage drueckt. EHRLICHE EINORDNUNG: der Limit-Fix ist notwendig, aber die Latte ist brutal — auf volatilen Stocks-in-Play am Open dauerhaft <6 bps zu fillen ist schwer, und Limit-Orders bringen Nicht-Ausgeführt-Risiko (verpasste Trades) statt nur billigerer Fills. Falls der Fix nicht reproduzierbar unter ~6 bps kommt, ist ORB-auf-Stocks-in-Play für Echtgeld NICHT tragfaehig und wir brauchen eine andere Edge. Das ist die ehrliche Antwort auf "ist DayPi am Maximum": nein, und der Backtest-Optimismus war ungedeckt.
WURZEL der Live-Slippage gefunden: Entries sind MARKET-Orders -> Backtest-Kosten (3bps) sind Fiktion2026-06-24
2026-06-24: Bei der Frage "ist DayPi am Maximum?" die Ausführung auseinandergenommen. BEFUND: daypi_live.py Z.227 reicht Entries als entry="market" ein. Eine Market-Order in den ersten Minuten nach Open frisst auf volatilen Stocks-in-Play (breiter Spread) einfach die vorhandene Liquiditaet -> genau daher RGNX +361 bps und O -56 bps Entry-Slippage live. Der Backtest unterstellt 3 bps (Regel #1 fordert >=6). Heißt: das ist NICHT primaer der SIP->IEX-Feed-Gap aus den frueheren Karten, sondern eine ~18x zu billige KOSTENANNAHME — das System rechnet sich profitabel auf Fills, die es live nicht bekommt. Das ist direkt Go-Live-Latte-Punkt (5) "Slippage frisst die Edge nicht". ZWEI Schritte eingeleitet (Regel #1, kein Knee-jerk): (a) Kosten-Stress-Test scripts/cost_stress.py (read-only, 504 Tage, Slippage 3/6/15/30/56 bps) -> beantwortet OOS, ob der Edge ehrliche Kosten ueberlebt oder tot ist; (b) Kandidat-Fix marketable Limit-Order mit bps-Cap statt Market (kappt Blowup-Fills, statt durch das Orderbuch zu rauschen) — erst nach OOS/robustness live. NICHTS live geändert.
Stopp-Hypothese GEGENGEPRUEFT (1 Jahr OOS) -> WIDERLEGT: enger ATR x0,5-Stop ist der beste, bleibt2026-06-24
2026-06-24: Die aus der Attribution geborene Vermutung "enger Stop wird am Open weggewhipt" sauber gegengeprueft statt live zu raten (scripts/stop_check.py, neu). 365 Tage SIP, 251 Handelstage, 70/30-Split (OOS 76 Tage, 186 OOS-Trades), echter Live-Filter, nur Stop/Methode variiert. ERGEBNIS eindeutig: der LIVE-Stop ATR x0,5 ist die BESTE Variante (OOS +0,048R, Sharpe 1,30, maxDD -8%, Full +16,9%). JEDE Verbreiterung ist schlechter: x0,75 -0,026R/Sharpe -0,82, x1,0 +0,010R, x1,25/x1,5 ~0, x2,0 negativ; OR-Gegenseite (weiter) nur +0,013R/Sharpe 0,35. -> Die Stop-Weite ist NICHT die Ursache des Live-Verlusts; verbreitern haette es VERSCHLIMMERT. SCHLUSS: der Live-Minus (-5,2% / 15 Trades) ist hoechstwahrscheinlich kleine Stichprobe + SIP->IEX-Feed-Unterschied (Backtest SIP, live IEX), nicht eine falsche Einstellung. ENTSCHEIDUNG: Stop bleibt ATR x0,5, NICHTS geändert (genau der Sinn von Regel #1 — kein Knee-jerk-Tuning auf 15 Trades). EHRLICH: auch die beste Variante ist nur +0,048R OOS = duenne Edge -> deckt sich mit "~500 Trades noetig". Zu beobachten bleibt der SIP->IEX- Gap (Slippage-Erfassung + weekly_review). stop_check.py bleibt als Re-Check-Werkzeug.
Attribution gebaut + erster Befund: Verlust hängt an Stop-Outs am Open, KEIN Trade erreicht das Ziel2026-06-24
2026-06-24: attribution.py gebaut (read-only, schluesselt P/L nach Richtung/Ausstiegsgrund/ rel-Volumen/Symbol-Typ/Uhrzeit/Slippage auf; läuft Sa 11:05 per cron mit). ERSTER BEFUND über die bisherigen 15 Live-Trades (= statistisch NOCH Rauschen, aber kohaerent): der Verlust ist konzentriert, nicht breit gestreut. (1) AUSSTIEGSGRUND ist die schaerfste Achse: 6 Stop-Outs = -4.404 $ (~84% des Gesamtverlusts), 9 Zeit-Flats zusammen nur -844 $ (ca. breakeven). (2) ENTSCHEIDEND: KEIN EINZIGER der 15 Trades hat sein 1,5R-Gewinnziel erreicht (0 Ziel-Exits). Heißt: die Open-Breakouts laufen live nicht durch -> sie kippen entweder in den (engen ATR x0,5-) Stop oder fransen bis zum Zeit-Flat aus. (3) Fast alle Entries liegen 09:30-10:00 ET, und genau die verlieren. (4) Shorts schlechter als Longs (-4.271 vs -977 $). HYPOTHESE (zu PRÜFEN, nicht zu handeln): enger Stop wird am volatilen Open weggewhipt UND/ODER die live (IEX) gewaehlten Setups folgen schlechter durch als im SIP-Backtest. NÄCHSTER SCHRITT wenn mehr Daten ODER per Backtest: Stop-Weite / Open-Cutoff gegenpruefen (robustness.py/optimize.py) — NICHT live spontan ändern (eiserne Regel #1).
Echtgeld-Latte verbindlich festgelegt (Mert abgenickt) — 25k Startkapital bestaetigt2026-06-24
2026-06-24 (Mert): Die Go-Live-Latte für Echtgeld ist verbindlich beschlossen. Echtgeld erst wenn ALLE 5 Punkte erfuellt: (1) >= 150 Live-Paper-Trades, (2) >= 3 Monate über mehrere Marktphasen, (3) unterm Strich positiv nach realen Kosten UND Schnitt-R statistisch > 0 (z>2), (4) groesster Drawdown <= 12%, (5) Slippage frisst die Edge nicht. Start dann mit 25k USD (PDT-Regel: bei 4+ Tagesgeschaeften/5 Tagen im Margin-Konto verlangt der US-Broker >= 25k, sonst sperrt er das Daytraden; Cash-Konto/Weniger-Handeln würden die Strategie kaputtmachen -> 25k ist für DayPis Handelsweise de facto Pflicht). Mert hat 25k als machbar bestaetigt. Sinn der Latte: sich Echtgeld NICHT in einer heissen Phase schoenreden -- nicht aufweichen. Stand jetzt weit entfernt (15 Trades, -5,2%).
Kein Auto-Self-Tuning (InvestPi-Lektion) + Wochen-Review gebaut + ehrlicher Live-Befund2026-06-24
2026-06-24: Mert wies darauf hin, dass das Schwester-Projekt InvestPi ein Self-Learning, das sich SELBST automatisch live umstellt, bewusst wieder ENTFERNT hat. Uebernommen: so ein Selbstumbau ist bei DayPi verboten (optimiert auf Rauschen, driftet unkontrolliert -> Gift für eine Echtgeld-Maschine). Trennung sauber gezogen: MESSEN+BERICHTEN ja (read-only), AUTOMATISCH SCHARFSTELLEN nein -> nur ein Mensch setzt Params live, und nur nach Out-of-Sample-Beweis (CLAUDE.md Regel #1). UMGESETZT: scripts/weekly_review.py gebaut — haelt Live gegen die Backtest-Erwartung (Trefferquote, Schnitt-R, P/L, Drawdown, Slippage) und urteilt ehrlich Edge-da/nicht-da/noch-Rauschen; soll wöchentlich per cron laufen (Sa 11:00, read-only, ändert nichts). loop/roadmap im Manifest entsprechend umgeschrieben. EHRLICHER LIVE-BEFUND (Anlass war genau diese Messung): seit eval_start 18.06. erst 15 abgeschlossene Trades, Summe -5.248 $ (~ -5,2%), Trefferquote 27% (Backtest-Erwartung ~50%), Schnitt-R -0,34. Das ist statistisch NOCH Rauschen (15 << die ~500 Trades, die eine so DUENNE Edge brauchen würde), aber die RICHTUNG ist das Gegenteil des Backtests -> beobachten, NICHT spontan nachjustieren. Wichtigste Erkenntnis für Mert: der erwartete Vorteil ist klein und die Streuung gross -> ein belastbares Urteil (und damit Echtgeld) ist Monate entfernt, Geld für Premium-Daten waere jetzt verbrannt.
Mission geschaerft: vollautonom, max. Rendite bei kontrolliertem Risiko -> Echtgeld2026-06-23
2026-06-23 (Mert): Ziel ausdruecklich gesetzt: DayPi soll VOLLAUTONOM laufen und maximale Rendite bei BEWUSST kontrolliertem Risiko erzielen, um irgendwann passives Echtgeld-Einkommen zu erzeugen. Mert hat wenig Daytrading-Erfahrung und volles Mandat erteilt (selbst entscheiden, aufraeumen, verbessern, tief recherchieren wenn noetig; kostenpflichtige Provider/Echtgeld vorher mit ihm klaeren). Beide Mission-Haelften sind gleich wichtig: max. Rendite OHNE Risiko-Disziplin = Konto-Tod, also ist die Survival-Schicht (Caps, Daily-Loss, Flat-before-Close, Not-Aus, OOS-Beweis vor scharf) nicht verhandelbar. UMGESETZT: CLAUDE.md neu geschrieben als Betriebs-Verfassung (Mission, eiserne Regeln, Echtgeld-Gate, Autonomie-Grenzen) und veralteten Pfad/User korrigiert (lief noch auf /home/pi + User pi, real läuft alles als User daypi unter /home/daypi/daytrader). Reihenfolge zum Echtgeld bleibt: erst Track-Record (ab 2026-06-18), dann vorab definierte Go-Live-Latte, dann ggf. Echtgeld (PDT >= 25k USD). Nächste Prioritaeten: Robustheit/Risiko > neue Features, solange wenig Live-Daten da sind.
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 über Ø taegl. $-Volumen): einen strengeren Liquiditaets-Filter zu setzen kostet ~KEINEN Edge (OR-R + Rendite über 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 nächster 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 täglich 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 täglich beim Watchlist-Bau; systemd-Singleton verhindert Ueberlapp). GREIFT AB NÄCHSTER 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% über 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 (wählt in Echtzeit die an dem Morgen tatsächlich 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 würde 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 heißt (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 Stück, das über 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% über 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 über die GESAMTE Schwellen-Spanne 1,0–3,5 durchgehend positiv (+0,12 bis +0,19R, Sharpe 3–5) — der Edge hängt NICHT am exakten Wert. 2,2 ist sogar leicht konservativer als das OOS-Optimum (~2,0: +0,188R) und liefert die höchste Full-Period-Rendite (+16,5%). Top-N-Sweep ebenfalls flach: Live Top-3 (+16,5%) solide, Top-4 OOS minimal stärker (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 über 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 für ~0$ entlarvt, bevor Echtgeld im Spiel war. Nächste 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 geprüft, 8 widerlegt) zur Frage, welche zweite, zu ORB möglichst 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 gelöscht (echte Kontoereignisse, Historie bleibt). Auswertung/Self-Learning zählen erst ab eval_start_date 2026-06-18 (erste angeglichene Session). Nur saubere, repraesentative Daten für die Echtgeld-Entscheidung.
Live an Backtest angeglichen — Edge-Filter + liquide Universe (war auseinandergelaufen!)2026-06-17
2026-06-17: Kritischer Fund beim Prüfen, ob LIVE überhaupt 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 geprüft: SIP ist auf dem Gratis-Konto für aktuelle Daten gesperrt -> IEX-Historie (19 Handelstage) reicht für 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 löschen = 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 könnte 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 über Wochen/Monate ueberzeugen. Folge für 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 läuft 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-Änderungen gingen sofort live, ohne Verlauf/Netz (anders als die Schwester investpi mit Git-Deploy). Jetzt: lokales Git-Repo in /home/pi/daytrader (.gitignore schließt Secrets .alpaca.env + data/ aus) plus taeglicher Auto-Commit (systemd daypi-autocommit.timer, 03:43) -> Änderungen nachvollziehbar und rueckrollbar. (HISTORISCH: hier stand zuerst "bewusst lokal belassen" — am 2026-06-17 REVIDIERT, siehe Eintrag oben: daypi wurde für 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).
GEPRÜFT: 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 über 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 zurück).
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 — können 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 — Im DayPi-Tab kurz schauen, ob die Trades laufen. Nur Aufsicht, keine Strategie-Urteile.
- Go-Live-Maszstab fuer Echtgeld festlegen einmalig — Eine Frage an dich - verträgst du bei 25.000 $ Echtgeld zwischendurch rund 10 % Minus? Sagst du nein, wird kleiner gehandelt. Keine Eile.
- Gesamt-Zeitverlauf-Chart im DayPi-Tab freischalten einmalig — Zwei Handgriffe, die DayPi nicht selbst darf: einmal 'sudo systemctl restart daypi-snapshot.service', dann der InvestPi-Session den Chart-Auftrag geben.
Notizen
LIVE-REALITAET (Stand 2026-08-09, ehrlich): DayPi läuft seit 2026-06-18 im Paper-Forward-Test. 108 Trades, -5.624 $ (-5,6%), Equity ~94.981 $. Der Verlust ist fast vollstaendig Juni (-4.609 $); Juli -1.330 $, August +942 $. Groesster Rueckschlag intraday -10,85% (27.07.) — Achtung: die Webapp zeigt -5,7%, weil sie nur Tagesschluss rechnet; für den Echtgeld-Maszstab zählt die INTRADAY-Zahl. --- WAS DER VARIANTEN-GEGENCHECK VOM 09.08. ERGAB: alle drei aus den Live-Daten abgeleiteten Verdachtsmomente (Shorts abschalten / Einstiegsfenster kuerzen / mehr Trades handeln) sind OOS auf beiden Feeds WIDERLEGT — Details im Entscheidungs-Log. Die Strategie bleibt in allen drei Punkten unveraendert. Geändert wurde nur die Positionsgroesse (1,0% -> 0,6% Risiko/Trade), weil die Strategie bei 1,0% strukturell über der 12%-Notbremse liegt. --- KORREKTUR DER ERWARTUNG: die früher hier genannte ``realistische IEX-Decke +0,039R`` ist NICHT belastbar. Derselbe Test vier Wochen später liefert +0,128R; die ehrliche Spanne über beide Feeds und Fenster ist +0,03 .. +0,13R. Damit liegt auch das Live-Ergebnis (-0,047R) noch innerhalb der Eigenstreuung des Backtests: es ist derzeit WEDER bewiesen noch widerlegt, dass die Edge existiert. --- WAS DAS PRAKTISCH HEISST: DayPi ist kein Projekt mit Entscheidungstermin, sondern ein Langzeit-Experiment. Ein statistischer Beweis braucht je nach wahrer Edge-Größe ~250 bis ~4.600 Trades, bei ~2,2 Trades/Tag also grob 0,5 bis 8 Jahre. Der Weg ``mehr handeln, um schneller Klarheit zu haben`` ist am 09.08. widerlegt worden (mehr Trades = schlechtere Trades + groesserer Rueckschlag). Laufen lassen kostet fast nichts; gestoppt wird nur bei echtem Negativ-Beweis (t<=-2) oder DD-Bruch. Self-Learning-Loop bleibt verboten (Regel #1). Echtgeld-Frage erst ab t>=+2 über >=400 Trades. Eigenes Paper-Konto — NICHT InvestPis. --- BEKANNTE UNSAUBERKEIT (bewusst nicht gefixt): simulate_symbol() kennt die Live-Grenze ``entry_cutoff 11:30`` nicht und nimmt Ausbrueche bis 15:50. Gemessen am 09.08.: Unterschied OOS +0,128R vs +0,126R = vernachlaessigbar. Nicht angefasst, weil eine Änderung an der Simulation die Vergleichbarkeit mit allen bisherigen Backtest-Logs zerstoeren würde.
Creator-Tooling2
BeatFactory🟢 läuftBeatFactory ist eine vollautomatische KI-Musik-Fabrik auf dem Raspberry Pi: Sie erfindet Beats (Suno AI), prüft ihre Qualität per Gemini-KI, baut ein animiertes YouTube-Video (OpenArt-Bild + Wan-Animation + FFmpeg) und lädt alles selbst hoch — täglich, ohne dass Mert etwas anruehren muss. FOKUS seit 07.07.2026: EINE Nische statt breit gestreut — "Sad Piano / Emotional" Type Beats (4 Sub-Stile: piano/guitar/dark/ambient), konzept-first (SEO auf "sad piano / emotional type beat" statt Mega-Artists) — weil Konkurrenz-Analyse zeigte: nur fokussierte Kanaele ranken. YouTube-Kanal: @VelvetBeats (Achtung: real @valvet_beats, Tippfehler-Task offen).
BeatFactory ist eine vollautomatische KI-Musik-Fabrik auf dem Raspberry Pi: Sie erfindet Beats (Suno AI), prüft ihre Qualität per Gemini-KI, baut ein animiertes YouTube-Video (OpenArt-Bild + Wan-Animation + FFmpeg) und lädt alles selbst hoch — täglich, ohne dass Mert etwas anruehren muss. FOKUS seit 07.07.2026: EINE Nische statt breit gestreut — "Sad Piano / Emotional" Type Beats (4 Sub-Stile: piano/guitar/dark/ambient), konzept-first (SEO auf "sad piano / emotional type beat" statt Mega-Artists) — weil Konkurrenz-Analyse zeigte: nur fokussierte Kanaele ranken. YouTube-Kanal: @VelvetBeats (Achtung: real @valvet_beats, Tippfehler-Task offen).
Funktionsweise
- Style-Wuerfel — Mood / Künstler / BPM / Tonart zufaellig aus 6 Stimmungen und 17 Künstler-Profilen
- Beat-Generierung — Suno V5.5 generiert instrumentalen Beat per API (Task-basiert, Poll bis fertig)
- QC-Schleife — Gemini benotet BEIDE Suno-Clips mit hartem Maßstab; unter 7,0 → neuer Versuch, max 3× = bester aus 6
- Mastering — Matchering mastert auf Profi-Referenztrack (Frequenz/Lautheit/Stereo, ~-12 LUFS) + Producer-Tag; Fallback loudnorm -14
- Hintergrundbild — OpenArt (Nano Banana 2) generiert passendes 16:9-Bild je Stimmung (z.B. Neon-Stadt für "dark")
- Loop-Animation — OpenArt Wan 2.7 i2v belebt das Bild zu ~5s Clip; Ping-Pong-Loop (vor+rückwärts) läuft 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 Künstler-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 OpenArt gemalt. Wan 2.7 belebt das Bild zu einem kurzen Videoclip, der per Ping-Pong- Technik endlos läuft. 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 läuft 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; älteste Eintraege fallen automatisch heraus.
output/DATUM_UHRZEIT/
Pro Produktions-Lauf ein Unterordner (z.B. output/20260616_2003/). Enthält: 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 für 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-Künstler (z.B. "Yeat x Cochise Type Beat"). 17 Künstler-Profile mit je 2 Referenz-Fotos für 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 läuft über 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 zurück.
5 · Hintergrundbild + AnimationPing-Pong-Loop
OpenArt malt ein 16:9-Bild zur Stimmung (z.B. neon-beleuchtete Stadt für "dark"). Wan 2.7 belebt es zu einem ~5-Sekunden-Clip. Ping-Pong-Technik (vor+rückwärts) ergibt einen nahtlosen Endlos-Loop. Fallback: Standbild.
6 · Video-Bau (FFmpeg)Full + Short
FFmpeg legt den Endlos-Loop unter die gesamte Beat-Länge, brennt den Beat-Titel als Text ein und ergibt das fertige 16:9-YouTube-Video. Parallel dazu: 9:16-Short (30 Sekunden) für 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, Schwächenprofil, verbesserter Prompt)
OpenArt / Nano Banana 2
Hintergrundbild-Generierung (16:9, 20 Credits pro Bild)
OpenArt / Wan 2.7
Bild-zu-Video-Animation (125 Credits pro Beat, 720p/5s)
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 Künstler-Referenz-Ordner
references/
{'2 Referenz-Beats (Pajel, Mero)': 'Stil-Analyse (Gemini) UND Master-Referenz für 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 für den nächsten Versuch
OpenArt-Maler
generiert stimmungsgenaues Hintergrundbild per KI
FFmpeg-Renderer
baut Video + Short (Regel-basiert, thermal-bewusst, 2 Threads)
YouTube-Uploader
lädt 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)
Visualsopenart_client (eigener OAuth-/MCP-Client, Nano Banana 2 + Wan 2.7) · 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 → OpenArt-Bild → Wan → FFmpeg → YouTube vollautomatisch. Läuft seit Ende Mai 2026.
Animierter Loop-Hintergrundfertig
Wan 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 prüft seine Temperatur vor jedem Render-Schritt. Über 72°C: Pause bis unter 60°C.
Fallback-Kettefertig
Bild failt → bg_westside-Standbild; Animation failt → Standbild; Mastering failt → Raw-Beat. Pipeline bricht nie.
Läuft — aktuelle Probleme
Suno-DNS/Timeout-Fehler haertenoffen
5 Läufe zwischen 2.-13.06 schlugen fehl (leere Output-Ordner). Ursache: Suno-API intermittierend nicht erreichbar. Retry/Backoff um den API-Call würde das loesen.
Geplant — nächste 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
Zweite Spur: Street-/Dark-Trap neben Sad Piano, gesteuert über Klang-Vorlagen2026-08-19
19.08.: Mert hat einen Lil-Baby-Type-Beat als Datei geschickt und damit den Weg aufgemacht, der beim Profi-Beat noch am Fingerabdruck-Abgleich gescheitert war — kleinere Free-Type-Beats sind offenbar nicht in Sunos Katalog. Der so erzeugte Beat bekam 7/10 und eine Merkfähigkeit von 6/10; beides die besten Werte seit Beginn der Messungen, wo sonst alles bei 5-6 und 4-5 lag. Erklärung: die Vorlage liefert Produktion und Klangbild, was reine Textprompts nachweislich nicht hinbekommen. Merts Entscheidung daraufhin: der Kanal bekommt eine ZWEITE Spur, hälftig — nicht mehr nur Sad Piano. Umgesetzt: BASE_STYLES trägt jetzt ein Feld "lane"; neu sind "Dark Trap" und "Melodic Street" mit eigenen Namen, eigenen Tags und einem eigenen Künstler-Pool (Lil Baby, Lil Durk, EST Gee, Rylo Rodriguez bzw. Hunxho, Rob49, BossMan Dlow, Luh Tyler). Visuell laufen sie über die vorhandenen Stimmungen mit, damit Bild, Animation und Thumbnail unverändert funktionieren. Der Anteil ist über TRAP_SHARE regelbar. Klang-Vorlagen: liegt in references/lane_trap/ eine Datei, wird der Beat bei etwa jedem zweiten Lauf über upload-cover erzeugt (audioWeight 0,30 — Sound ja, Melodie nein), sonst über den normalen Weg. Die Vorlage wird dafür kurz unter zufälligem Namen öffentlich abgelegt, weil Suno sie selbst abholen muss, und danach sofort wieder gelöscht. Ende-zu-Ende geprüft: Vorlage bereitgestellt, Auftrag angenommen, zwei Clips à 150 s, Datei danach weg. Risiko, das Mert kennt: zwei Spuren auf einem Kanal brauchen länger, bis YouTube das Publikum sortiert hat — die Empfehlungsrate kann kurzfristig sinken.
Merts Verdacht bestätigt: Beats liefen mit krummem Tempo — jetzt exakt ganzzahlig2026-08-19
19.08.: Präzise Tempomessung (librosa-Beat-Tracking + Ausgleichsgerade durch alle Beat-Zeitpunkte, mittelt über 300+ Beats). Ergebnis für "Nightfall" vom 18.08.: gemessen 141,134 BPM — im Titel und in der Beschreibung stand 137, also der gewürfelte Wunschwert, den Suno nie umgesetzt hat. Zwei Fehler in einem: falscher Wert UND krummes Tempo. Praktische Folge für einen Rapper, der den Beat in die DAW lädt und 141 einstellt: nach 135 Sekunden liegt das Raster 129 ms daneben, rund ein Drittel Schlag. Zum Vergleich: Merts Favorit A1 aus dem Vocal-Sample-Test lag mit 130,020 BPM fast exakt (23 ms Versatz über die volle Länge) — es ist also Zufall pro Generierung, nicht konstant. Die Messung am Profi-Referenztrack war nicht verwertbar (660 ms Streuung = der Beat-Tracker ist ausgestiegen), daraus lässt sich also NICHT ableiten, dass menschliche Beats sauberer sind. Eingebaut: measure_bpm() + snap_to_integer_bpm() laufen nach dem Mastering. Der Beat wird per atempo-Filter auf den nächsten ganzen Wert gezogen (hier Faktor 0,99905, also 0,1% — unhörbar), Kontrollmessung danach 141,003 BPM. Der gemessene Wert ersetzt außerdem den gewürfelten in Titel, Beschreibung, Tags und history.json. Sicherungen: kein Zug bei unsauberer Erkennung (>60 ms Streuung) oder Abweichung über 0,5 BPM; Original bleibt dann einfach stehen. Nebeneffekt: "exakt 141 BPM" ist gegenüber anderen KI-Kanälen ein Verkaufsargument.
OpenArt-Reserve auf Null gesetzt — Animationen laufen wieder (Mert-Entscheidung)2026-08-18
18.08.: Die Bremse in openart_client.py hielt 4.000 Credits für Merts eigene Generierungen und andere Projekte frei. Da der Stand mit 2.893 darunter lag, wurde die Wan-Animation bei jedem Lauf übersprungen und das YouTube-Video war ein Standbild. Auf Merts Ansage ist die Reserve jetzt abgeschaltet (OPENART_RESERVE=0 in der .env, kein Codeeingriff — jederzeit rueckgaengig). Geprueft: Animation wieder freigegeben. Folge, die im Blick bleiben muss: BeatFactory zieht 145 Credits pro Lauf und darf das Kontingent jetzt bis auf Null leerfahren. Mit dem aktuellen Stand reicht es für rund 20 tägliche Läufe; danach fällt die Animation von selbst aus (Standbild-Fallback greift, die Pipeline bricht nicht ab) und andere Projekte gehen leer aus.
Merts Hörurteil: Vocal-Chop-Richtung kommt fest rein — als Pool, nicht als Schablone2026-08-18
18.08.: Von allen heute erzeugten Beats hat Mert A1 aus dem Vocal-Sample-Test gewählt (hochgepitchter, zerschnittener Soul-Chop als Hauptmelodie über dem Klavier). Sein Urteil: kein klassischer Sad-Type-Beat mehr, aber die Richtung stimmt — mit der ausdruecklichen Auflage, dass NICHT jeder Beat dieselbe Vokal-Spur bekommt. Umsetzung: neuer Baustein VOCAL_SAMPLES mit zwölf klar verschiedenen Ausfuehrungen (gepitchter Soul-Chop, wortlose Fläche, Gospel-Chor-Stabs, rückwärts laufender Swell, Vocal-Ad-lib als Perkussion, verwaschene Tape-Stimme und weiter). Greift per Zufall in rund 60% der Beats (VOCAL_SAMPLE_CHANCE in der .env regelbar), die übrigen 40% bleiben bewusst ohne Stimme. Beide Prompt-Wege sind angeschlossen: der Wuerfel-Bau und der Gemini-Bau, wobei Gemini zusaetzlich angewiesen ist, die vorgegebene Vokal-Ebene neu zu formulieren und nie zweimal dieselbe zu nehmen. Stichprobe von acht Prompts geprüft: acht verschiedene Vokal-Ebenen bzw. bewusst keine. Ab dem Job um 20:03 aktiv.
Vocals als Sample statt als Gesang: bester Genre-Treffer bisher, Note bleibt bei 62026-08-18
18.08., zweite Idee von Mert. Vier Clips in zwei Ansaetzen erzeugt: (A) hochgepitchter, zerschnittener Soul-Vocal-Chop als Hauptmelodie, (B) wortlose Stimmfläche als Klangbett mit antwortenden Chops. Wertung 6/5 bzw. 6/6 — also dieselbe Bandbreite wie alles andere heute, ABER der Genre-Treffer steigt auf stabil 8/10 (vorher 7), und der QC lobt die Vokal-Ebene ausdruecklich ("ethereal vocal pad layers create a good sense of space"). Das passt zur Analyse der Nische, in der genau diese Schicht in allen vier Top-Beats vorkommt. Wichtige Einschränkung zur Bewertung selbst: nach rund zwanzig heute bewerteten Beats nennt der QC IMMER dieselben drei Mängel (synthetisches Klavier, 808 matscht mit dem Klavier, dumpfe Hi-Hats) — unabhaengig davon, was geaendert wurde. Entweder ist das die echte Obergrenze dessen, was Suno liefert, oder der Prüfer kann oberhalb von 6 nicht mehr unterscheiden. Ab hier entscheidet Merts Ohr, nicht die Maschine.
Getestet: Lied mit Gesang erzeugen und Vocals rausrechnen bringt keinen besseren Beat2026-08-18
18.08., Merts Idee — Suno steckt in vollstaendige Lieder mehr Arrangement als in reine Instrumentals, also Lied MIT Gesang erzeugen und die Stimme per Stem-Trennung entfernen. Technisch geht das: POST /api/v1/vocal-removal/generate mit taskId + audioId aus einem EIGENEN Generierungs-Task, type=separate_vocal (Vocals + Instrumental) oder type=split_stem (Einzelspuren). Ergebnis liefert direkte Download-Links. Zwei Durchlaeufe gefahren, davon einer als sauberer Direktvergleich mit identischem Style-Prompt: instrumental=True kam auf 6 und 5, das aus dem Lied gestrippte Instrumental auf 5 (im ersten Durchlauf ebenfalls 5). Also kein Gewinn, eher leicht schlechter — plausibel, weil das Arrangement um die Stimme herum gebaut ist und nach dem Entfernen ein Loch hat; die Kritikpunkte bleiben dieselben (matschige 808, statische Hi-Hats, MIDI-artiges Klavier). split_stem konnte nicht mehr geprüft werden, das Suno-Guthaben ging während des Tests aus.
Auslese statt Ueberredung: bester aus 6 Clips (Mert-Entscheidung)2026-08-18
18.08.: Nachdem Modellwechsel, Prompt-Ueberarbeitung, neues Nischen-Referenzprofil und neue Mastering-Referenz alle bei 6/10 landen, bleibt als wirksamer Hebel nur mehr Auswahl. Mert hat sich für die teurere Variante entschieden: QC-Hürde bleibt bei 7,0 und die Schleife laeuft bis zu 3 Suno-Durchgaenge (QC_MAX_RETRIES=2), jeder liefert 2 Clips → der beste aus 6 gewinnt, und jeder Folgeversuch startet mit dem verbesserten Prompt aus dem QC. Kosten steigen damit von 12 auf bis zu 36 Suno-Credits pro Beat (~1.080 statt ~360 im Monat); die Laufzeit des naechtlichen Jobs waechst um grob 6 Minuten. Zurueckdrehen geht jederzeit über QC_MIN_SCORE / QC_MAX_RETRIES in der .env, ohne Codeaenderung.
Audio-Referenz hochladen scheitert an Suno selbst — zwei Negativ-Ergebnisse2026-08-18
18.08.: Mert hat einen professionellen Emotional-R&B-Type-Beat als Datei geliefert (references/ref_emotional_rnb_typebeat.mp3). Zwei Wege damit getestet, beide ohne Erfolg: (1) Suno upload-cover (Datei als Klang-Vorlage, audioWeight 0,30 und 0,55) bricht beide Male ab mit "This audio matches an existing recording in our catalog" — Suno erkennt bekannte Aufnahmen per Fingerprint und verweigert sie. Damit ist der Weg "Profi-Beat hochladen, aehnliches erzeugen" für fremde Musik grundsätzlich zu. Offen bleibt er nur für EIGENES Material (eigener Beat als Vorlage, oder Persona per personaId aus dem besten eigenen Beat). (2) Mastering-Referenz getauscht (Rap-Song mit Gesang → echter Instrumental-Type-Beat) und denselben Rohbeat einmal mit jeder Referenz gemastert: QC 6 zu 6, kein messbarer Unterschied. Die neue Referenz bleibt trotzdem gesetzt, weil ein Instrumental die logisch richtige Vorlage ist. Bilanz aus allen Versuchen des Tages: Modellwechsel (Lyria), Prompt-Ueberarbeitung, Nischen-Referenzprofil und Mastering-Referenz landen ALLE bei 6/10. Die verbleibenden Kritikpunkte sind immer dieselben und liegen in dem, was Suno generiert: statische 4-Takt-Schleife, mechanische Hi-Hats ohne Velocity, 808 ohne saubere Sub-Definition. Realistisch hilft nur noch Auslese statt Ueberredung — mehr Kandidaten erzeugen und den besten nehmen.
Referenzprofil aus den Top-Beats der eigenen Nische neu gebaut (via Gemini + YouTube-Link)2026-08-18
18.08.: yt-dlp bekommt vom Pi aus nur noch 403 von YouTube (Bot-Schutz, auch mit aktueller Version, anderen Player-Clients und PO-Token-Versuch). Lösung: Gemini kann eine YouTube-URL DIREKT hören — analyze_audio() nimmt jetzt neben Dateien auch Links entgegen. Damit die vier meistgesehenen Beats unserer Nische analysiert (6,7 Mio / 6,4 Mio / 4,2 Mio / 2,7 Mio Aufrufe) und reference_analysis.json ersetzt; vorher lag dort EIN jazziger Lo-Fi-Song vom 01.06. Gemeinsame DNA aller vier: akustisches Grand Piano mit viel Hall (nicht Felt-Piano oder Rhodes), atmosphaerische WORTLOSE Vokal-Flächen und Vokal-Chops als Klangschicht, tiefe gleitende 808 bzw. warmer Sub, minimale Half-Time-Drums, 3 von 4 in gis-Moll, 116-130 BPM. Folge-Änderungen: (1) Das pauschale "no vocals" in Prompt und negativeTags hat genau die Vokal-Flächen unterdrueckt, die den Sound der Nische ausmachen — verboten ist jetzt nur noch Leadgesang/Rap. (2) Das Referenzprofil ist im Prompt-Bau vom "optionalen Gewuerz" (50% Chance, max. 1 Element) zum Rueckgrat geworden, weil es endlich zur Nische passt. Ergebnis-Kontrolle: Ein Testbeat mit neuem Setup bekommt weiterhin 6/10 — die Prompt-Ebene allein schließt die Lücke also NICHT. Die wiederkehrenden Kritikpunkte sind Mix-Themen (808 matscht mit dem Klavier im selben Frequenzband, Hi-Hats dumpf statt knackig, Klavier ohne Anschlagsdynamik). Naechster Hebel ist deshalb die Audio-Referenz (upload-cover mit niedrigem audioWeight) — dafür braucht es eine echte Datei, kein YouTube-Link.
Ehrlicher QC deckt auf: unsere Beats sind 6/10, nicht 9/10 — plus Längen-Fix2026-08-18
18.08., ausgeloest durch Merts Hoereindruck ("klingt nicht wirklich gut"). Drei Befunde: (1) Der QC-Prompt zog seit dem Nischenwechsel (07.07.) das alte Referenzprofil mit rein — reference_analysis.json enthält nur EINE Analyse, einen jazzy Lo-Fi-Track vom 01.06. Jeder Sad-Piano-Beat wurde also gegen R&B/Rhodes gemessen, und der improved_prompt-Retry hat brav in die falsche Richtung nachgebessert. Referenzblock aus dem Scorer entfernt. (2) Gemini hat mit dem alten Prompt praktisch alles mit 8-9 bewertet → das QC-Gate (7,0) hat nie gegriffen und die Wahl zwischen den zwei Suno-Clips war Zufall. Neuer Prompt mit harter Kalibrierung (10 = nicht von einem echten Produzenten unterscheidbar, "die meisten KI-Beats landen bei 5-7") plus zwei neue Kennzahlen genre_match und memorable. Ergebnis: dieselben Kanal-Beats vom 13.08. und 10.08. bekommen jetzt 6/10 statt 8-9 — Mert hatte recht, der alte Prüfer hat geschmeichelt. Wiederkehrende echte Schwächen laut neuem QC: matschige 808 ohne Definition, steife Hi-Hats ohne Rolls, Klavier ohne Anschlagsdynamik, Melodie als generische Schleife statt Hook. (3) Suno lieferte oft nur 77-83s. Der Parameter 'duration' (nur V5_5 + customMode, 10-360s) ist jetzt gesetzt (MAX_BEAT_SEC+15 = 150s) und live geprüft: 2 von 2 Clips exakt 150s.
Getestet: Google Flow Music (Lyria 3 Pro) schlägt Suno NICHT — Suno bleibt2026-08-14
14.08.: Flow Music ist das frühere Riffusion/ProducerAI, im Feb 2026 von Google gekauft, im April auf Lyria 3 umgebaut. Entwickler-Zugang läuft NICHT über eine Flow-API, sondern über die normale Gemini-API — Modelle 'lyria-3-clip-preview' (30s, $0,04) und 'lyria-3-pro-preview' (bis ~3 Min, $0,08), erreichbar mit dem GEMINI_API_KEY, den BeatFactory ohnehin hat (client.interactions.create, Antwort ist base64-MP3 44,1 kHz). A/B-Test 5 Lyria-Beats gegen 5 Suno-Beats, bewertet mit demselben Gemini-QC: Lyria Ø 8,8 — Suno Ø 8,8. Kein messbarer Qualitätsvorsprung, dafür drei harte Nachteile: (1) Tonart und BPM aus dem Prompt werden ignoriert (140 BPM/C#-Moll angefordert → 78-85 BPM, G-Moll geliefert) — die Pipeline schreibt beides in Titel und Beschreibung. (2) Instrumenten-Treue schwach (Gitarren-Prompt kam als Rhodes-Piano zurück). (3) Nur EIN Clip pro Call statt Sunos zwei, dazu sporadische 400 'content_blocked' (2 von 8 Calls) → effektiv ~$0,16/Beat statt ~$0,08 plus Retry-Logik. Zweiter Durchlauf im Fremdgenre (New German Trap, je 3 Beats): wieder Gleichstand 8,7 zu 8,7, Genre-Treffer bei beiden 9-10/10. Zwei Korrekturen zum ersten Test: (a) das BPM-Problem betrifft nur Half-Time-Material — im deutschen Test traf Flow 135/140/140 BPM sauber; (b) Flow liefert konstant ~115 s, Suno nur 77-83 s, für ein Type-Beat-Video also klar zu kurz. Die Tonart trifft Flow weiterhin nur in 1 von 3 Fällen. Fazit: kein Wechsel. Erneut prüfen, wenn Lyria Seed-/Tempo-Parameter bekommt. Hörprobe beider Tests: https://pokepi.tail6ec256.ts.net/flowtest/ (Dateien in /home/pi/gateway/flowtest). Prompt-Erkenntnis nebenbei: Lyria will Fließtext nach der Formel Genre+Stimmung+Instrumente+Tempo+"Instrumental." und kann per [00:00]-Zeitstempeln ein Arrangement bauen — Sunos Komma-Deskriptorenliste ist dort das schwächere Format.
QC-Gate lief still ins Leere (Files-API 403) — auf Inline-Audio umgestellt2026-08-14
14.08.: Beim Lyria-Test aufgefallen — die Gemini-Files-API liefert in Kombination mit gemini-3.5-flash seit heute 403 PERMISSION_DENIED. Die Pipeline fängt den Fehler ab ("QC übersprungen") und vergibt still Score 5,0: kein Qualitäts-Gate, keine Tonart-Erkennung, kein improved_prompt-Retry — der Beat wäre trotzdem hochgeladen worden. Fix: analyze_audio() schickt Dateien bis 18 MB jetzt direkt als Bytes mit (types.Part.from_bytes), Files-Upload nur noch als Fallback für größere Dateien. Verifiziert, QC läuft wieder.
Gemessen: Reichweite kommt aus Empfehlungen, NICHT aus der Suche — SEO-first ist überholt2026-08-04
04.08.: Erste echte Traffic-Quellen-Messung (YouTube-Analytics, Video "Cold Nights" vom 02.08. mit 152 Aufrufen — bestes langes Video des Kanals, ~3,5x über dem nächstbesten). Aufschlüsselung: 122 Aufrufe aus YouTube-EMPFEHLUNGEN (80%), 17 direkt, nur 7 aus der SUCHE (4,6%), 4 Kanalseite. Damit ist die Annahme vom 07.07. ("konzept-first SEO ist der Hebel") widerlegt: Titel und Tags bringen praktisch nichts, weil über die Suche fast niemand kommt. Was der Algorithmus stattdessen belohnt: Thumbnail-Klickrate, Sehdauer und Likes. Passende Belege am selben Video — Like-Rate 3,8% gegen 1,7% Kanal-Schnitt, und die Aufrufkurve stieg nach 2 Tagen noch immer an. Gegenprobe gegen die naheliegende Fehldeutung "der Artist-Name The Kid LAROI war es": ein anderes Kid-LAROI-Video (11.07.) liegt bei 2,5 Aufrufen/Tag — der Name allein erklärt nichts. Offene Schwachstelle: durchschnittliche Sehdauer nur 0:33 von 2:17 (24,8%) — das ist der eigentliche Hebel, weil der Algorithmus genau daran misst. Wichtig: Basis ist EIN Video, also Richtung statt Beweis — die Traffic-Verteilung ist aber eindeutig genug, um Aufwand weg von Tag-/Titel-Optimierung zu lenken.
Kanalname bleibt "Valvet Beats" — Code an den Kanal angeglichen statt umgekehrt2026-08-04
04.08. (Entscheidung Mert): Der Tippfehler im Kanalnamen ("Valvet" statt "Velvet") wird NICHT korrigiert — Mert kann den Namen nicht ändern. Konsequenz: der Code zieht nach, nicht der Kanal. Geändert in beat_generator.py: CHANNEL_NAME auf "Valvet Beats", neuer CHANNEL_HANDLE "@valvet_beats" (ersetzt den toten Link "@VelvetBeats", der bis dahin in JEDER Videobeschreibung ins Leere lief), Credit-Hinweis und Thumbnail-Branding unten rechts ziehen jetzt beide aus CHANNEL_NAME statt aus fest verdrahtetem Text. Damit ist das Branding ab dem nächsten Beat durchgängig. Offen: die ~152 BEREITS hochgeladenen Videos tragen den toten Link weiterhin in der Beschreibung — Nachtragen wäre möglich, kostet aber API-Kontingent (50 Einheiten pro Video gegen 10.000 pro Tag, ein Upload allein kostet 1.600), muss also gestaffelt laufen und ist noch nicht entschieden.
Bild + Animation von fal.ai auf OpenArt umgestellt2026-07-27
27.07. (Wunsch Mert): fal.ai fliegt raus, Hintergrundbild und Loop-Animation kommen jetzt von OpenArt — Bild via Nano Banana 2 (20 Credits), Animation via Wan 2.7 i2v 720p/5s (125 Credits, hat wie Wan 2.2 Start-/End-Frame-Steuerung). Besonderheit: OpenArt hat KEINE API mit Schlüssel, der einzige programmatische Zugang ist ihr MCP-Server hinter OAuth. Damit der Cron-Job trotzdem unbeaufsichtigt laufen kann, wurde ein eigener OAuth-/MCP-Client gebaut (openart_client.py): einmaliger Browser-Login von Mert, danach erneuert sich der Zugang automatisch über einen Refresh-Token (.openart_token.json, chmod 600). Risiko bewusst in Kauf genommen: wird der Zugang widerrufen, greift der bestehende Standbild-Fallback — die Pipeline bricht nicht, die Videos wären nur unbewegt, bis Mert sich einmal neu einloggt. End-to-End getestet am 27.07.: Login steht, Bild + Animation + Ping-Pong-Loop laufen durch (Bild ~15s, Animation ~40-105s).
Credit-Bremse — BeatFactory darf das Kontingent nicht leersaugen2026-07-27
27.07.: Das OpenArt-Abo liefert 12.000 Credits pro MONAT (nicht einmalig) und wird NICHT exklusiv von BeatFactory genutzt — Mert generiert selbst auf openart.ai, weitere Projekte sollen folgen. Ein täglicher Cron-Job, der ungebremst 145 Credits pro Lauf zieht, würde das Kontingent still auffressen. Deshalb prüft openart_client vor jeder Animation den Stand: liegt er nach dem Job unter OPENART_RESERVE (Default 4.000), wird die Animation übersprungen und das Video läuft mit Standbild weiter — statt anderen Projekten den Saft abzudrehen. Verbrauch BeatFactory bei täglichem Upload: ~4.350 von 12.000 (~36%).
Motion-Prompts entschärft — Wan 2.7 nimmt Prompts wörtlicher2026-07-27
27.07., beim Test der Umstellung aufgefallen und sofort behoben. Wan 2.7 folgt dem Prompt deutlich strenger als Wan 2.2, mit zwei sichtbaren Folgen: (1) Der Motion-Prompt beschrieb bisher selbst eine Szene ("rainy window at night, warm lamp light") — Wan 2.7 schrieb daraufhin das Bild um: aus grauem Regentag wurde Nacht, eine Lampe ging an. (2) "rain falling" ohne Ortsangabe ließ es sichtbar IM Innenraum regnen. Fix: Motion-Prompts beschreiben nur noch Bewegung und frieren Szene/Licht/Tageszeit explizit ein, Wetter wird nach draußen gebunden; MOTION_NEGATIVE deckt Relighting/Szenenwechsel zusätzlich ab. Nachgetestet und bestätigt. Grundsätzlich richtig so: jede Stimmung hat 3 verschiedene Hintergrund-Szenen, ein szenenbeschreibender Motion-Prompt kann nie zu allen passen.
Pivot auf EINE Lane umgesetzt — "Sad Piano / Emotional"2026-07-07
07.07., direkt nach der Konkurrenz-Analyse gewählt (Mert) und im Code umgebaut. Statt 20+ Zufalls-Artists × 6 breite Moods jetzt EINE Nische mit 4 emotionalen Sub-Stilen: piano (sad piano), guitar (emotional guitar), dark (dark emotional), ambient (ambient emotional). Umbau komplett: Leads/Vibes/Drums/Bass/Texturen auf melancholisch (Klavier/Gitarre/Streicher/Chor, weiche 808/Sub); Mood-Keys neu (piano/guitar/dark/ambient — ergeben zugleich SEO-Begriffe); BEAT_NAMES emotional (Tears, Regret, Nostalgia…); Artist-Pool auf emotionale Acts (Juice WRLD, Lil Peep, The Kid LAROI, Rod Wave, Powfu…); Thumbnail-Farben gedämpft/kalt; BG-Bilder + Animation melancholisch (Regen, Einsamkeit); Master-Referenzen angepasst. SEO KONZEPT-FIRST: Titel/Tags führen mit "sad piano / emotional / sad type beat", Artist nur ~50% & sekundär — das ist der rankbare Hebel für einen kleinen Kanal. Voll getestet (alle 4 Moods, Thumbnail, Smart-Prompt, Titel/Tags). Greift ab nächstem Lauf. Erwartung realistisch: Fokus ist der stärkste Hebel, aber Geld braucht weiter den BeatStars-Funnel + Namens-Fix (offene Mert-Tasks).
Konkurrenz-Analyse → Kernproblem ist fehlender Fokus, nicht die Nische2026-07-07
07.07., Analyse erfolgreicher Type-Beat-Kanäle via YouTube-API. Befund: JEDER Gewinner besitzt EINE Lane — STORM (159k) nur Lil Baby, Z3NA (146k) nur Afrobeat, LEXNOUR (281k) Konzept-Keywords (Sad Piano/Diss Track/Aggressive statt Artist), Blanq (163k) R&B/Club, prodbycircus (295k, erst seit Mai 2025!) #2000stypebeat + Meme-Titel, HugeBoi (493k) nur 86 Videos mit Persönlichkeit. Unser Profil (20+ Zufalls-Artists × 6 Moods, breit gestreut, steriler Titel) ist exakt das, was NICHT rankt → erklärt die flachen Views besser als "Nische zu voll". prodbycircus beweist: JETZT noch einsteigbar, wenn fokussiert. Kernlektion: EINE Lane wählen + besetzen; Konzept-Keywords (sad piano, rage, diss) schlagen umkämpfte Mega-Artists; Titel Keyword-stapeln + Persönlichkeit. Nächster Schritt offen (Mert): Lane festlegen → dann Pipeline darauf umbauen.
Abbruch-Frage → fairer Test mit Deadline (Ziel = Geld)2026-07-04
04.07., Mert fragt ob/wann abbrechen ("bekommen keine Views mehr"). Zahlen-Check: 6 Wochen, 58 Videos, 5 Abos, ~2.085 Views, kein Aufwaerts-Trend, fast null Interaktion — die Verbesserungen vom 29.06.-02.07. haben nicht gezogen. Ziel = Geld. Kern-Erkenntnis (unbequem): der Kurs wurde nie wirklich als Geld-Test gefahren — BeatStars-Funnel gar nicht angeschlossen (0 Kaufweg) UND Kanal- Name/Handle-Tippfehler (Valvet vs Velvet) macht den Funnel-Link tot. Beides sind offene MERT- Aufgaben, keine Technik-Grenze. Entscheidung: NICHT jetzt abschalten, sondern erst beide Leaks fixen, dann fairer 3-Wochen-Test bis 25.07. mit harter Messlatte (1 Verkauf ODER Video >300 Views ODER Abos >25). Verfehlt → abbrechen oder auf weniger umkaempfte Nische pivotieren. Ehrliche Erwartung niedrig, aber so wird wenigstens das Richtige getestet.
Beat-Vielfalt erhöht + Shorts zeitversetzt geplant2026-07-02
02.07., Reaktion auf "Beats klingen zu ähnlich". Root-Cause: die Style-Bausteine waren Synonyme (alle Bässe = 808-Knock, alle Drums = HiHat-Rolls, alle Leads = Bell/Pluck), der Kreativitäts-Regler stand fix niedrig (weirdness 0.30, styleWeight 0.80 → "bleib brav"), und der "smart prompt" würzte JEDEN Beat mit der DNA der EINEN analysierten Referenz (Chill-Jazz). Entscheidung Mert: NUR Bausteine entschärfen, KEINE neuen Sub-Genres (Trap-Rahmen bleibt, such-/verkaufbar). Umgesetzt: LEAD_INSTRUMENTS mit echter Instrumentenvielfalt (Piano/Gitarre/ Flöte/Chor/Sax/Kalimba/Steel-Drum…), BASS_STYLES divers (Sub/Sine/Plugg/Reese/verzerrt statt 6× 808), DRUM_STYLES mit echten Feels (sparse/halftime/swung/ohne-Rolls), TEXTURES erweitert + wieder in den Prompt; weirdness jetzt gestreut 0.42–0.62, styleWeight 0.60–0.72 (pro Beat zufällig); Referenz nur noch als leichte Würze in 50% der Fälle (2 statt 5 Elemente). SHORTS: weiter 2/Beat, aber via YouTube-publishAt zeitversetzt veröffentlicht (+2h / +18h) — privacyStatus 'private' + publishAt, damit sie nicht im selben Feed gegeneinander laufen.
Thumbnail-CTR + Tags geschärft (Reaktion auf stagnierende Views)2026-06-29
29.06., Anlass: Views pendeln 2–77 (Schnitt ~25), fast null Likes/Kommentare — kein Bug, sondern kalter Kanal + überfüllte Nische. Im Code drehbar = Auffindbarkeit + Klickrate, also zwei Fixes. THUMBNAIL (Center-Layout): Hierarchie gedreht — Artist-Name jetzt GROSS (54px statt 36, der Suchbegriff, nach dem geklickt wird), Beat-Name 168 statt 200; FREE-Badge ergänzt; Hintergrund satt statt flau (Vignette statt flacher 40%-Abdunklung, Tint 0.16, globaler Farb-/Kontrast-Punch fürs Feed). TAGS: Hochintent-Varianten nach vorn (free/2026/„x"-Combo je Artist) + BPM-Suchtags. WICHTIG dabei: der Upload vom 29.06. ("Eclipse") war zuvor exakt am Tag-Limit gecrasht (HttpError 400 invalidTags) — YouTube zählt mehrwortige Tags MIT Quotes (+2). Fix: zentrale Funktion _youtube_safe_tags() (Quote-Aware-Cap 460 Zeichen, entfernt < >, entdoppelt) direkt IM Upload-Pfad → jeder Upload geschützt. Eclipse danach manuell nachgereicht (fertiges Render wiederverwendet, frische Artists da Original ungeloggt). Reichweite hebt das nicht magisch — Haupt-Engpass bleibt Vertrauen+Konsistenz über Monate. Nur die im Code beeinflussbaren Hebel ausgereizt.
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-KI-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 07/2026, täglicher Upload ≈ 30 Beats/Monat)2026-06-19
Bild+Animation laufen seit 27.07. über OpenArt — Abo "Advanced" mit 12.000 Credits PRO MONAT (nicht pay-per-use, nicht einmalig): Wan 2.7 i2v 720p/5s = 125 Credits + Nano Banana 2 Bild = 20 Credits → 145 Credits pro Beat. Bei täglichem Upload (~30 Beats) also ~4.350 von 12.000 Credits = nur ~36% Auslastung, rund zwei Drittel des Kontingents bleiben ungenutzt. Kein Engpass — eher die Frage, ob man die Reserve in Qualität steckt (1080p statt 720p = 175 statt 125; 10s statt 5s = 250 statt 125). Rest weiter pay-per-use: Suno ~8-10 Credits/Beat ≈ ~$0,06-0,10 (× Ø-Versuche der QC-Schleife, Retry kostet je einen weiteren Suno-Call!), Gemini QC+Prompt ~$0,02. → laufende $-Kosten nur noch ~$0,10/Beat ≈ $3/Mon + Pi-Strom ~$1, dazu das OpenArt-Abo. Matchering-Mastering, 2. Short, YouTube/Telegram = $0 (lokal bzw. gratis).
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., zusätzlich: (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 KI-Hintergrundbild + Künstlername 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/Bild → grob 3× höhere Lauf-Kosten als vorher. (Überholt seit 27.07.: Bild+Animation laufen über das OpenArt-Abo statt pay-per-use.)
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 für Suchbegriffe wie "yeat type beat" schlicht nicht ausgespielt. 5-7 Views sind in den ersten Wochen normal. Echte Hebel: (1) Kanal-Branding fixen (heißt noch "Mert"/@mert5089), (2) mehr Uploads (täglich statt 3×/Woche), (3) auf Shorts setzen — die funktionieren schon, (4) weniger übermächtige Künstler targeten, (5) Geduld: 3-6 Monate Konsistenz.
Animierter Loop-Hintergrund (Wan i2v + Ping-Pong)2026-06-17
Statisches KI-Bild wird per OpenArt Wan 2.7 i2v zu ~5s Clip animiert → Ping-Pong-Loop (vor+rückwärts) läuft 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 (OpenArt down/Timeout), fällt das Video sauber auf das Standbild zurück — 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 für diesen JobProjektstart 2026-05
BeatFactory-Cron (Di/Do/Sa 20:03) läuft per klassischem crontab, kein systemd-Timer. Begründung: einfacher, keine Service-Dateien nötig, reicht für 3×/Woche.
Offene Aufgaben für Mert
- YouTube-Analytics-Zugang freischalten (Statistiken automatisch auswerten) einmalig — Einmal den Google-Login durchklicken, damit ich Sehdauer und Klickraten selbst auslesen kann statt per Screenshot.
- OpenArt-Credits im Blick behalten routine — Einmal im Monat den Credit-Stand prüfen — bleibt dauerhaft viel übrig, stecken wir es in bessere Bildqualität.
- TikTok/Instagram-Zugang für Shorts-Crossposting bereitstellen einmalig — TikTok- und Instagram-Account für "Velvet Beats" anlegen und mir die Zugänge geben, dann baue ich das Crossposting ein.
- BeatStars-Store einrichten und Link hinterlegen (Geld-Funnel) einmalig — Ohne BeatStars-Link kann niemand einen Beat kaufen, der Ertrag bleibt also 0 €. Store aufsetzen, Auszahlung einrichten, Link schicken.
- BeatFactory-Test — Zwischenstand prüfen (Abbruch-Frage vertagt) routine — Einmal im Monat schauen, ob die einzelnen Videos besser werden (Aufrufe pro Video, Sehdauer) — nicht die Gesamtzahl.
Notizen
Stand 04.07.2026: Reichweiten-Check nach ~6 Wochen: Kanal 5 Abos, 58 Videos, ~2.085 Views gesamt. Full-Beats Median 14 Views (max 72), Shorts Median 34 (max 77), fast null Likes/Kommentare. KEIN Trend nach oben — Gesamt-Views steigen nur, weil mehr hochgeladen wird (Laufband, kein Wachstum). Die Verbesserungen vom 29.06.-02.07. (Thumbnails, Tags, Beat-Vielfalt, Shorts-Timing) haben die Zahlen bisher nicht bewegt. Ziel laut Mert (04.07.) = GELD verdienen; Entscheidung: fairer Test mit Deadline 25.07. ZWEI Geld-Leaks gefunden, beide bei Mert offen: (1) BeatStars-Link fehlt → gar kein Kaufweg, Ertrag garantiert 0. (2) Kanal-Tippfehler "Valvet Beats"/@valvet_beats statt "Velvet Beats"/@VelvetBeats → Funnel-Link in jeder Beschreibung tot, Branding wirkt kaputt. Erst Leaks fixen, DANN 3 Wochen testen — sonst Test mit eingebautem Nullergebnis. Ehrliche Erwartung trotzdem niedrig: Beat-Verkaeufe brauchen Volumen/Reputation, bei diesem Traffic in 3 Wochen unwahrscheinlich. Fallback bei Fehlschlag: Pivot auf weniger umkaempfte Nische (Lofi/Sleep/Ambient) mit derselben Pipeline. Thermal-Guard aktiv. KOSTEN (täglich ≈ 30 Beats/Mon, Stand 27.07.): Bild + Animation über das OpenArt-Abo "Advanced" mit 12.000 Credits/Monat; 145 Credits/Beat (20 Bild + 125 Animation) → ~4.350/Mon = ~36% Auslastung, reichlich Reserve. Pay-per-use bleiben nur Suno ~$0,06-0,10/Beat (Retries kosten extra) und Gemini (Cent-Beträge) → ~$3-4/Mon + Pi-Strom ~$1, plus das OpenArt-Abo. Matchering & 2. Short gratis (lokal).
ReelForge🟢 läuftAll-in-one-Werkbank für Reels: jede Art von Reel wird als eigenes Format eingehaengt, aus Song + Text entsteht ein vertikales Video (1080×1920). Seit 2026-07-27 komplett in der Cloud — Oberflaeche als Cloud-Run-Dienst (per Passwort geschuetzt, von jedem Geraet erreichbar), Rendern als Cloud-Job, der nur während der Arbeit existiert. Früher Desktop-App auf Merts Windows-PC; der PC wird nicht mehr gebraucht. Gebaut wird von mehreren Claude-Sessions gleichzeitig — je Reel-Art eine, jede in ihrem eigenen Format-Ordner. Gehört zu instapi / Mila-Content-Pipeline. 4 Formate fertig, 3 geplant — das ist der Anfang, nicht das Ziel.
All-in-one-Werkbank für Reels: jede Art von Reel wird als eigenes Format eingehaengt, aus Song + Text entsteht ein vertikales Video (1080×1920). Seit 2026-07-27 komplett in der Cloud — Oberflaeche als Cloud-Run-Dienst (per Passwort geschuetzt, von jedem Geraet erreichbar), Rendern als Cloud-Job, der nur während der Arbeit existiert. Früher Desktop-App auf Merts Windows-PC; der PC wird nicht mehr gebraucht. Gebaut wird von mehreren Claude-Sessions gleichzeitig — je Reel-Art eine, jede in ihrem eigenen Format-Ordner. Gehört zu instapi / Mila-Content-Pipeline. 4 Formate fertig, 3 geplant — das ist der Anfang, nicht das Ziel.
Funktionsweise
- Anmelden — Adresse im Browser oeffnen, Passwort eingeben (30 Tage angemeldet)
- Audio-Input — MP3/WAV hochladen → landet im Zwischenspeicher, Laenge wird gelesen
- Lyrics + Format — Text tippen, Format wählen (4 aktiv), Schrift/Farben einstellen
- Render — Cloud-Job faehrt hoch, baut das Reel (FFmpeg + Whisper + moviepy), verschwindet wieder
- Output — MP4 im Browser herunterladen; Pi holt es zusätzlich ab → instapi postet
Wie ReelForge funktioniert
Dritter Bildstil mannequin — und er ist ab sofort die VoreinstellungBild
Merts Verdacht am 2026-08-20- "ich habe das gefühl diese 3d paper stil oder vox passt nicht ganz zu unserem stil". Nach einer Stilprobe die Entscheidung- "dann lass uns alle zukünftigen videos im diesen stil jetzt erstellen." GRUND ist der Ton, nicht der Look- Bastelpapier wirkt bei Krieg, Geld und Macht niedlich und untergräbt den Ernst. Gesichtslose Puppen geben Distanz und stehen für "irgendein Mensch" — genau die Vox-Erzählweise. RECHERCHE ergab keine brauchbare Vorlage- alles zu "mannequin prompt" ist Mode und Handel (Ghost-Mannequin). Der Materialblock ist aus einer japanischen Vorlage umgebaut, die Satzreihenfolge bleibt die von VORLAGE_3D. VIER FESTE ENTSCHEIDUNGEN im Materialblock- matt statt lackiert (lackiert liest sich als Schaufenster), echter Stoff an der Puppe (sonst kippt es ins Spielzeughafte), Nahtlinien ohne Kugelgelenke (sonst Holz-Gliederpuppe), hartes gerichtetes Licht (weiches Licht gibt Stock-Foto). DIE PUPPE IST KEINE PFLICHT (Merts Zusatz)- eine Objektszene bleibt eine Objektszene, der Puppen-Satz hängt nur an Szenen, deren motiv/zusatz das Wort "mannequin" trägt. ZWEI NEUE SPERREN gegen den stillen Rückfall- Personenwörter ohne "mannequin" brechen ab (sonst malt das Modell echte Menschen und EINE Szene fällt lautlos aus dem Stil), und "aufbau: true" ist verboten (ein echtes Set setzt sich nicht vor der Kamera zusammen). OFFEN- die Langform (langauftrag.py) importiert die Collage-Bausteine fest und ist vom Wechsel unberührt. Reels wären damit Mannequin, Langvideos Collage. Steht als Aufgabe.
Der Clip erzählt nichts, er erweckt das Bild zum LebenBild
Merts Maßstab am 2026-08-20, nach drei verworfenen Bewegungsaufträgen zur selben Szene. NACHGEMESSEN an AKTE 09- alle sechs Clips waren Mikro-Aufträge ("sways by a hair", "trembles once", "a fraction") und kamen gut zurück; bei der Bremse hat Flow die Klinke sogar von sich aus geschwenkt, obwohl der Auftrag Stillstand verlangte (zwei Einzelbilder aus 06_close-view.mp4 zeigen es). Das Modell legt also von selbst zu — wer groß bestellt, bekommt Unsinn. ZWEITE REGEL aus demselben Tag- das Standbild ist der ERSTE Frame, es zeigt also den Zustand VOR der Bewegung. Merts Befund an einem Auftrag, dessen Bild das bereits gekappte Seil zeigte- am Clipende wuchs ein zweites, heiles Seil ins Bild. FOLGERUNG- Szenen, die eine große Bewegung brauchen (ein Axthieb), gehören gar nicht erst auf die Liste der bewegten. Beides in formate/vox/SKILL.md.
Der Aufbau-Clip wird rückwärts abgespielt — Flow kann es nicht andersBild
Merts Vergleich zweier echter Clips am 2026-08-12 hat eine Beschränkung des WERKZEUGS freigelegt, keine des Auftrags. In Google Flow ist das gelieferte Bild IMMER das erste Bild des Clips. Ein Aufbau, der auf diesem Bild endet, ist dort also nur zu haben, indem das Modell ihn rückwärts ausspielt — und genau das tut es. Merts Befund zu seiner Original-Vorlage- "der hat es perfekt zerlegt". Zu unserem Auftrag, der zusätzlich "the provided image is the FINAL frame" sagte- "der anfang des clips war das bild, dann sind die elemente rausgeflogen und dann wieder rein", dafür fehlerfrei. LÖSUNG- umgedreht wird NICHT im Auftrag, sondern im Schnitt. Der Zielname trägt "_rueck_" (dieselbe Bauart wie "_ab…_" und "_beleg_", weil der Schnitt das Drehbuch nicht kennt), bau.segment_aus_video hängt einen reverse-Filter davor. Zu sehen ist damit exakt Merts Vorlage. ABGRENZUNG zum Pingpong-Rücklauf, der als Notbehelf gilt- dort läuft derselbe Clip hin UND zurück, und "Wind weht nicht rückwärts" (Merts Urteil 2026-07-31). Hier läuft er NUR rückwärts, und ein umgekehrter Zerfall IST ein Aufbau. ZWEI FALLEN MITENTSCHÄRFT- (1) bestellen.py vergab für Clips einen eigenen Dateinamen und hätte das "_rueck_" still verloren; beide Wege fragen jetzt dieselbe Stelle. (2) Kommt ein Clip doch vorwärts zurück, ist die Korrektur eine Umbenennung statt einer Codeänderung — deshalb sitzt der Schalter im Namen. NICHT GEMACHT, obwohl zwischendurch gebaut- den Auftrag selbst zum Zerfall umschreiben. Das war eine Lösung für ein Problem, das die Vorlage schon gelöst hatte, und der dritte Fall an einem Tag, in dem Merts Wortlaut ohne Not verlassen wurde. Seine Vorlagen stehen jetzt wörtlich in formate/vox/VORLAGE_PAPIER3D.md, mit jeder Abweichung samt Grund daneben.
Zweiter Bildstil papier3d — Papier-Schichten neben der flachen CollageBild
Mert am 2026-08-12 mit einer fertigen Prompt-Formel- "ich hab eine neue style art gefunden wie unsere vox videos erstellt werden." Es ist NICHT eine Abwandlung des Collage-Stils, sondern das Gegenteil- räumliches Papier-Diorama aus Karton und Kraftpapier, dutzende einzeln geschnittene Schichten mit sichtbarer Dicke und tiefen Schattenspalten, statt flach von oben fotografierter Collage mit Halbton-Fotoschnipseln. ENTSCHEIDUNG- danebenstellen statt ersetzen ("stil: papier3d" im Drehbuchkopf, weglassen = collage), damit sich beide Looks an einem echten Reel vergleichen lassen und die vier fertigen Reels nicht angefasst werden. Der Collage-Stil ist nachweislich Wort für Wort unverändert (gegen den alten Stand gemessen). DREI STELLEN, AN DENEN MERTS VORLAGE UNSEREM AUFBAU WIDERSPRACH- (1) sie verbietet JEDE Schrift, unsere Etiketten sind aber ein Vox-Merkmal. Merts Antwort darauf noch am selben Tag- "wir können die prompts ja so anpassen dass auch schrift erzeugt wird, solange es gut aussieht." Daraus wurden ZWEI BAUARTEN, gewählt nach Länge- bis 10 Zeichen und EIN Etikett kommen ausgeschnittene Papierbuchstaben mit eigener Dicke und eigenem Schatten (das ist der Look), länger oder mehrere stehen gedruckt auf einem Kärtchen, und das Kärtchen ist die Papierschicht. Grund- jeder frei ausgeschnittene Buchstabe ist eine eigene Form mit eigenem Schatten; bei vier sieht das grossartig aus, bei vierzehn wird es Buchstabensalat MIT Schlagschatten, und der fällt stärker auf als flacher. Die Frage im Schlussbild steht deshalb immer gedruckt auf einem Papierbanner. Die Grenze ist gemessen, nicht geraten- RADIUM, AKTE, GENEHMIGT, SPERRE liegen darunter, das gescheiterte OSTEUROPÄERIN darüber; (2) sie hält das untere Bilddrittel nicht frei, dort liegen unsere Untertitel, also steht die Regel jetzt im Stilblock; (3) "ultra-detailed, 8K" ist im Collage-Stil am 2026-07-31 rausgeflogen, bleibt hier aber drin, weil ein Diorama von scharfen Schnittkanten und Schattenspalten lebt. BEWEGUNG- Merts Videoauftrag IST ein Aufbau (Schicht für Schicht von hinten nach vorn), deshalb ist er bei diesem Stil die Voreinstellung statt angefordert werden zu müssen. Seine Vorlage rechnet mit ZEHN Sekunden (7 bauen, 3 stehen), unsere Clips sind drei (bestellen.CLIP_DAUER, Haken fünf) — die Zahlen werden deshalb aus der bestellten Cliplänge gerechnet und nicht abgeschrieben, unter fünf Sekunden warnt prompts.py laut. Der Stil hängt am DREHBUCH, nicht an der Szene- zwei Bildstile in einem Reel sehen nach Fehler aus, nicht nach Stilmittel. OFFEN- noch kein Bild damit erzeugt.
Themenwahl ist jetzt eine Sperre, keine Bitte — thema.yaml als NachweisSkript
Merts Frage am 2026-08-11- "wie loesen wir das jetzt am besten, dass bei jedem neuen reel ein thema recherchiert wird um ggf aktuelle themen in der welt zu nutzen?" Eine Anleitung loest es nicht. Dreimal belegt- die Kaltlese stand in zwei Dokumenten und wurde uebersprungen, die Render-Regel stand fett in der CLAUDE.md und wurde zweimal ignoriert, und dieselbe Sitzung, die den Flow-Vorrang aufschrieb, hat zweimal OpenArt gerechnet. Deshalb derselbe Bau wie bei der Kaltlese- ein BEQUEMERER WEG plus ein NACHWEIS. "themen anlegen <kennung> <ordner>" legt den Reel-Ordner an, schreibt thema.yaml und ein kette.txt-Geruest mit Anlass und Hintergrund; ungeprüfte Themen weist es ab. mach.py verlangt thema.yaml und baut sonst nicht (--ohne-thema uebergeht das und protokolliert es laut). Damit faengt jedes Reel bei der LAGE an statt bei einem Einfall — genau der Fehler, aus dem AKTE 01 entstand.
Keine Automatisierung, solange das Format im Aufbau istBetrieb
Merts Ansage am 2026-08-11- "es soll auch erstmal kein cron laufen, wir sind bisher im aufbau bis die videos perfekt sind erst dann." Gilt für die ganze Kette, nicht nur die Themensuche- kein Timer fuers Sammeln, kein automatischer Upload, kein Sammellauf, der von allein losgeht. BEGRUENDUNG- solange das Format wackelt, würde Automatisierung nur schneller Mittelmaessiges produzieren und die Fehler verstecken, an denen gerade gearbeitet wird. Jeder Lauf soll ausgeloest werden, damit jemand hinschaut. Wieder aufgreifen, wenn die Videos sitzen — und dann als eigene Entscheidung, nicht nebenbei.
Der Haken-Test- breit heißt voraussetzungslos, nicht aktuellSkript
Merts Frage am 2026-08-11 nach dem Cardboard-Cinema-Reel (Millionen Aufrufe auf einem frischen Kanal)- "waere es vielleicht schlauer, seinen stil zu kopieren?" Die Messung sagt- der Look ist nicht der Grund. 111 handgesetzte Geraeusche, 35 Woerter je Gedanke, eine Frage die 60 Sekunden offen bleibt — das ist die Mechanik, und die hat Aktenlage inzwischen. Der echte Unterschied liegt im erreichbaren PUBLIKUM und ist eine Größenordnung gross- "warum bauen Biber Daemme" interessiert jeden, "Mathias Rust, Mai 1987" interessiert Geschichtsinteressierte. PRUEFBAR GEMACHT durch den Haken-Test- lässt sich die Eroeffnung formulieren, OHNE einen Eigennamen und OHNE eine Jahreszahl? Biber ja, Rust nein. Namen und Zahlen duerfen vorkommen, nur nicht in den ersten Sekunden und nie als Eintrittskarte. Daraus folgt ein wiederholbares Muster für Aktenlage- "Warum ist [Alltagsding] so, wie es ist?" → weil etwas Schreckliches passiert ist. Jeder kennt den Gegenstand, fast niemand den Grund, und der Grund ist per Definition dunkel. Zehn geprüfte Kandidaten liegen in themen.yaml unter der Quelle muster-alltagsding. ENTSCHEIDUNG gegen einen Stilwechsel- nach drei Videos den Look zu tauschen heißt, nach drei weiteren wieder zu tauschen und nie zu wissen, was gewirkt hat.
Bilder- ERST Google Flow, OpenArt nur als RueckfallKosten
Ausdrueckliche Ansage von Mert am 2026-08-11, nachdem ich an einem Tag ZWEIMAL selbstverstaendlich OpenArt-Credits gerechnet und vorgelegt hatte- "du willst schon wieder über openart die bilder erstellen, vermerke fest in den claude anweisungen dass erst flow und dann openart falls keine credits mehr verfügbar." Er hat bei Google Flow ein laufendes Kontingent (50 Tokens am Tag plus 200 im Monat), das ungenutzt dalag, während ich Credits verplante. URSACHE- mach.py bestellt bei OpenArt, das ist der bequeme Weg, und der gewinnt gegen einen Merksatz, wenn er nicht aufgeschrieben ist — dieselbe Mechanik wie bei der Render-Sperre. Steht jetzt in CLAUDE.md und oben in SKILL.md, nicht in einer Fussnote. Der Ablauf ist- prompts -o auftrag erzeugen, auftrag.html in Flow abarbeiten, Dateien unter den Namen aus auftrag.json ablegen, abnahme + material prüfen, DANN mach (findet alles vor und bestellt nichts). Vor jeder OpenArt-Bestellung erst klaeren, ob Flow noch Kontingent hat- eine genannte Zahl ist keine Genehmigung.
Humor- trocken, im BILD, nie im Sprechertext — und Buerokratie ist das MaterialSkript
Merts Wunsch am 2026-08-11- "etwas humor einbauen, es darf gerne leicht dunkler humor sein." Vermessen am Cardboard-Reel- dort liegt KEIN einziger Gag im gesprochenen Wort, die Stimme klingt durchgehend wie eine BBC-Doku. Die Dissonanz zwischen ernstem Ton und alberner Bildebene IST der Witz; sobald der Erzaehler mitwitzelt, bricht die Fallhoehe zusammen und die Autoritaet, die die Fakten traegt, ist weg. ABER der Text liefert die Steilvorlage (Merts Praezisierung)- "Beavers are the second best builders on Earth" ist sachlich und enthaelt doch eine Rangliste, die ein Bild woertlich nehmen kann (Podium, Platz 2). Also- so formulieren, dass ein Bild den Satz beim Wort nimmt — Wertungen, Redewendungen, Amtssprache. FÜR AKTENLAGE ist das Material Buerokratie, und deren dunkler Witz ist immer derselbe- das System dokumentiert die Katastrophe korrekt, während sie passiert (Haekchen bei "keine besonderen Vorkommnisse", Namensschild wird abgeschraubt, Wimpelkette über leerem Schreibtisch). Umgesetzt ohne neues Werkzeug im vorhandenen Drehbuch-Feld "zusatz"- hoechstens EINES je Bild und DREI je Reel, sonst wird aus einer Handschrift eine Comedy-Nummer. GRENZE- das ist eine Themenfrage. Rust traegt es, die Radium-Maedchen nicht. Prueffrage- ist die Fallhoehe die Absurditaet eines Systems oder das Leid eines Menschen? Über Institutionen darf man spotten, über Opfer nicht. Details in SKRIPT.md.
Zweite Bewegungsart- AUFBAU (Collage Animation) neben dem bisherigen DriftBild
Merts Beobachtung an echten Vox-Videos (2026-08-11)- "die animation war eher so ein aufbau, wo faeden und karteikarten sich zusammengesetzt haben." Der Fachbegriff ist COLLAGE ANIMATION, definiert als "the visible assembly of pieces into a timed composition" — und ReelForge konnte bisher nur die andere Haelfte- DRIFT (Rauch steigt, Flamme flackert). Der Drift-Auftrag KANN das nicht, er sagt woertlich "Every element keeps its shape, size, position", also das Gegenteil von Zusammensetzen. Deshalb eine EIGENE Vorlage (prompts.BEWEGUNG_AUFBAU), gewählt über "aufbau: true" im Drehbuch; ein Auftrag, der beides sagt, lässt das Modell entscheiden und dann macht es keins von beidem richtig. DER TRICK, DER ES SICHER MACHT- das gelieferte Bild wird als LETZTES Bild des Clips angesagt, nicht als erstes. Damit weiss das Modell, wohin alles gehört, und erfindet keine Teile. Dazu drei Regeln aus dem Leitfaden zu Gemini Omni Flash (dem Videomodell in Google Flow)- Kamera immer ausdruecklich nennen (auch "static" ist dort ein Befehl), "Keep everything else identical." gegen Abdriften, und Text im Bild festnageln, weil er sich beim Aufbau mitbewegt. Details in SKILL.md.
Kaltlese ist eine Stolperstellen-Suche, kein Vollstaendigkeits-PrueferSkript
Merts Klarstellung am 2026-08-11, nachdem ein Rust-Skript zweimal nachgebessert wurde, um jeden Einwand eines Kaltlesers zu beantworten- "das skript muss nicht immer alle fragen beantworten, vorallem bei den reels nicht ... Spannung und attention ist das einzig wichtige." Ein Kaltleser schreibt zwei Sorten Einwaende auf, und sie sind das Gegenteil voneinander. OFFENE FRAGE (behalten)- der Zuschauer weiss, dass er etwas noch nicht weiss, und bleibt deshalb. STOLPERSTELLE (raus)- eine Zeile, die man zweimal lesen muss, weil sie zweideutig ist oder sich widerspricht; beim Reel gibt es kein zweites Lesen. Zwei echte Faelle aus demselben Skript- "oben feiert man den Grenzschutz" (stolz oder Feiertag?) und "wenn jeder nur seinen Befehl befolgt" (es hatte gerade niemand einen Befehl bekommen). Wer alles beantwortet, macht aus einem Reel ein Referat. mach.py hat seitdem --ohne-kaltlese, das die Sperre uebergeht und das LAUT ins Protokoll schreibt. Ausfuehrlich in SKRIPT.md.
Fünf bis sieben bewegte Szenen je Reel — das Budget begrenzt nicht mehrBild
Google Flow gibt Mert 50 Tokens PRO TAG plus 200 im Monat obendrauf; ein Video kostet 7 (4 Sekunden). Das sind 1.700 Tokens oder 242 Videos im Monat. Damit ist das Kontingent KEIN Begrenzer mehr — bisher waren 1 bis 2 Szenen je Reel bewegt, weil Bewegung der teuerste Posten der Kette war. Der Engpass ist jetzt die TAGESGRENZE- 50 Tokens sind genau 7 Videos, ein Reel mit mehr als sieben bewegten Szenen braucht also zwei Tage oder frisst die 200er-Reserve. Wer an einem Nachmittag fertig sein will, plant hoechstens sieben. Was wirklich begrenzt, ist die Physik-Regel- animiert wird nur, wo sich etwas bewegen KANN, typisch vier bis sieben Szenen je Reel. Position nach AUFMERKSAMKEIT, nicht nach Motiv- der Haken (50-60 % aller Abbrueche), die zweite Abbruchwelle bei Sekunde 15-25 (laengste Strecke ohne Belohnung), und direkt VOR der Pointe (nicht auf ihr — dort zieht Bewegung das Auge vom Text weg). Bewegte Zeilen kurz schreiben- ein 4-Sekunden-Clip auf eine 5,6-Sekunden- Szene ist Faktor 1,39, ab 1,6 läuft der Clip rueckwaerts zurück und man sieht die Umkehr. Details in SKILL.md.
1 · Song hochladenAudio
MP3 oder WAV reinziehen. Landet im Cloud-Zwischenspeicher, Laenge wird automatisch gelesen.
2 · Format & Text4 Formate
Eines der 4 Formate wählen (Lyrics-Karaoke, Story-Scroll, WhatsApp-Chat, Spotify-Player). Lyrics eintippen, Farben und Schrift anpassen.
3 · VorschauPreview
Eine Handy-Vorschau zeigt live, wie das Reel später aussieht.
4 · RendernCloud-Job
Ein Klick weckt den Cloud-Job. Der baut das 1080×1920-Reel samt automatischem Karaoke-Sync und verschwindet danach wieder — bezahlt wird nur die Rechenzeit.
5 · Reel nach instapiMP4 → Post
Fertiges MP4 direkt im Browser herunterladen. Zusätzlich holt der Pi es automatisch ab und legt es instapi hin — kein manuelles Rueberziehen mehr.
Daten & Quellen
Audio
User-Upload (MP3/WAV) oder lokale Clip-Sammlung
Lyrics
Textfeld im UI ([Verse]/[Chorus]-Parsing)
Format-Templates
4 aktiv (lyrics_std, story_scroll, whatsapp_chat, spotify) — 3 weitere geplant
Wer/was arbeitet
Web-Oberflaeche (cloud_server.py)
Cloud-Run-Dienst "reelforge", schlanker Container, Passwort davor. Drei Abteile: Start (Reel-Art wählen) · Reelmaker (bauen) · Ordner (fertige Reels + Clips)
Render-Job (cloud_render.py)
Cloud-Run-Job "reelforge-render", 8 Kerne, existiert nur während er rechnet
Render-Engine
FFmpeg + faster-whisper + stable-ts (Silbenzuordnung) + moviepy
Pi
holt fertige Videos ab und uebergibt sie an instapi
Technik
UIReact 19 + TypeScript, gebaut mit Vite (seit 2026-07-29) — vorher React 18 vom CDN, im Browser uebersetzt
UI-BausteineTailwind 4 + eigenes Design-System (web/src/theme.css); shadcn/ui angebunden
BackendFlask + gunicorn als Cloud-Run-Dienst
RenderFFmpeg (drawtext/ASS-Untertitel, filter_complex, overlay)
STT / Syncfaster-whisper (Karaoke-Wort-Sync)
Captionscaption_engine.py + caption_bridge.py → zwei Looks (Held, Plakat) in je 4 Varianten, ASS via pysubs2
Video-Libsmoviepy (Clip-Komposition)
CloudGoogle Cloud Run (Belgien), Zwischenspeicher gs://reelforge-503709-jobs
Clip-ErzeugungOpenArt MCP · PixVerse V6 · 9:16 · 540p · 5 s · 50 Credits je Clip
Adressehttps://reelforge-1085372544136.europe-west1.run.app
Pi-Pfad (Quellcode)/home/pi/reelforge — bis 2026-07-28 unter /home/pi/instapi/scripts/reelforge
AufbauFormat-Register: eine Reel-Art = ein Ordner formate/<id>/ (Rendern + Oberflaeche), wird automatisch eingesammelt — keine Liste zum Eintragen
VersionierungEigenes Git-Repo seit 2026-07-28 (vorher Teil des instapi-Repos)
Wo ReelForge hin will
✅ In der Cloud, von jedem Geraetfertig
Oberflaeche und Rendern laufen als getrennte Cloud-Dienste. Der Windows-PC wird nicht mehr gebraucht, das Handy reicht.
✅ Werkbank statt Einzelstueckfertig
Eine Reel-Art ist jetzt ein Ordner, der automatisch gefunden wird. Neue Arten kommen dazu, ohne dass jemand am Kern schrauben muss — Voraussetzung dafür, dass mehrere gleichzeitig daran bauen können.
Oberflaeche auf ein tragfaehiges FundamentPhase 1+2 fertig
Phase 1 (Bauweise: Vite + React 19 + TypeScript + Tailwind) und Phase 2 (Design-System, Deko raus, eine Sprache) sind fertig. Offen: Bildschirme neu denken (Navigation bei vielen Reel-Arten, Mediathek mit Suche/Filter), Grundbausteine auf shadcn/ui, Abnahme gegen die Vercel-Pruefregeln. Details und Begruendungen: UI-ROADMAP.md
Clip-Strecke — Szenen aus dem Songtextals nächstes
Der größte Brocken und das eigentliche neue Produkt: aus dem Text Szenen-Prompts ableiten, Clips über OpenArt erzeugen, in die Bibliothek legen und beim Rendern der passenden Zeile zuordnen. Bisher existiert davon KEIN Code, gemacht wird es von Hand.
Fertige Reels automatisch zu instapioffen
Der Pi holt fertige Videos ab und uebergibt sie an instapi zum Posten. Heute laedt Mert sie noch selbst herunter.
Die drei gesperrten Formateoffen
Pinterest Slideshow, POV Nachtfahrt, Black Screen Reveal — Ordner stehen schon, Kachel ist gesperrt, Renderer fehlt.
WhatsApp-Chat Stufe 2offen
Laenge auf 25 s, Stille-Intro als Hook, Song-Drop am Wechselpunkt.
Strichfiguren-Erklaerer — vom Rechner gezeichnetim Bau
ERSTES REEL LÄUFT seit 2026-07-31- "Deine schoenste Erinnerung ist die, die am wenigsten stimmt" — 13 Szenen, 52 s, 1080x1920, in der Cloud gerendert (render:v26). 18 Posen als reine Daten, Regie im Skript ([pose:nachdenken]), das grosse Wort sitzt auf dem gesprochenen Wort. Kachel bleibt gesperrt, bis Mert das Reel abgenommen hat. WARUM DIESE ART- Minimalistische Strichfiguren statt Bildmaterial, komplett von Code gezeichnet. Keine Materialkosten (nur die Sprecherstimme), keine Rechtefragen, jedes Thema möglich — auch abstrakte, an denen die Archiv-Doku ausfaellt. Der Stil ist belegt- ein Kanal dieser Machart kam laut Recherche in 90 Tagen auf 20 Mio. Aufrufe, Publikum vor allem 18-24. Die Begruendung traegt unabhängig von der Zahl- Strichfiguren senken die Denklast, kein Gesicht lenkt ab. UEBERHOLT- die urspruengliche Schätzung "zwei bis drei Wochen für Figurenbibliothek plus Bewegungssystem". Das Geruest stand an einem Tag, weil das Bewegungssystem entfallen ist- der Stil verlangt eine STILLSTEHENDE Figur (siehe Entscheidungs-Log).
Archiv-Doku — Erklaer-Reel aus echtem Filmmaterialauf Eis
Technisch fertig, aber auf Eis. Mert nach der Vorschau des ersten Reels- "tote idee, das ist null catchy". Die ganze Kette funktioniert (Suche, Auswahl, Holen, Sprecher, Musik, Schnitt) und bleibt liegen; die Kachel ist gesperrt. Wiederbelebbar, falls sich ein Thema findet, bei dem echtes Archivmaterial traegt. Was daraus weiterlebt- Clips können an beliebiger Stelle einsteigen, die Cloud rendert beliebige Formate, und die Browser-Vorschau vor dem Schnitt. SEIT 2026-08-10 LEBT DER KERN DER IDEE IN VOX WEITER- echtes Material als ZUTAT (hoechstens ein Drittel der Szenen, in den Papierschnitt-Look gebracht) statt als eigenes Format. Genau diese Variante war nie probiert worden. Suche und Herkunftsnachweis aus quellen.py werden dafür mitbenutzt.
Weitere Reel-Artenlaufend
Der offene Teil des Ziels — jede neue Art bekommt eine eigene Session und einen eigenen Ordner. Was gebaut wird, entscheidet Mert.
Entscheidungs-Log
Kaltlese prueft jetzt auch Grammatik und Faktenspringen
Merts Auftrag am 2026-08-19, nachdem er im fertigen Reel ueber "Von da an fahren Menschen. Oben wird teuer." gestolpert ist- "pruefe in zukunft bei der kaltlese noch ob alles gramatikalisch sinn macht und nicht von fakt zu fakt gesprungen wird". WARUM DAS DURCHGERUTSCHT IST- der Satz entstand beim KUERZEN. Das Skript war zu lang, die Zeile wurde zusammengestrichen, und dabei fiel das "es" heraus. Alle Pruefungen blieben gruen- skript.py zaehlt Zeichen und Zeilen, sprechtext.py sucht Meta-Saetze, die Kaltlese fragte nach Verstaendnis. Keines davon liest Grammatik. Und der Leser VERSTEHT so einen Satz trotzdem, meldet ihn also nicht von allein. NEU sind zwei Pflichtfragen im Auftrag (kaltlese.FRAGEN und FRAGEN_LANG)- (4) Ist jeder Satz richtiges Deutsch, mit der richtigen Fassung daneben. (5) Wird von Fakt zu Fakt gesprungen, also stehen zwei Zeilen nebeneinander, ohne dass die zweite aus der ersten folgt. Frage 5 misst dasselbe wie der rote Faden in SKRIPT.md, aber am fertigen Text und aus dem Ohr eines Fremden statt aus der Absicht des Autors. Bewaehrt hat sich das Muster schon bei der Langform- dort ist "wo hast du den Faden verloren" die schaerfste der vier Fragen.
Sprechtempo wird geregelt, die Betonung bleibt Gluecksache
Merts Vergleich der beiden Fassungen von AKTE 09 (2026-08-19)- "ich finde die geschwindigkeit bei version 2 besser aber betonung und sprechweise von version 1 besser". BEIDE LIEFEN MIT DENSELBEN EINSTELLUNGEN- derselbe Text, dieselbe Stimme, Stabilitaet Ausdruck, Faktor 1,06. Der Unterschied kommt allein aus der Erzeugung- Fassung 1 sprach 654 Zeichen in 67,8s (9,6 Zeichen/s), Fassung 2 668 Zeichen in 64,7s (10,3). ElevenLabs wuerfelt Tempo UND Betonung bei jedem Lauf neu; das steht als Rauschen von rund fuenf Sekunden schon in skript.PAUSE_SEKUNDEN. WAS SICH LOESEN LAESST- das Tempo. Ein fester Prozentsatz verschiebt beide Laeufe um denselben Betrag und laesst den Abstand stehen. Deshalb regelt bau.tempo_fuer() jetzt auf eine ZIELRATE (10,3 Zeichen je Sekunde der rohen Aufnahme, genau Merts Tempo), begrenzt auf 0,95 bis 1,25. Fassung 1 haette damit 1,068 bekommen, Fassung 2 bleibt bei 0,998. WAS SICH NICHT LOESEN LAESST- die Betonung. Dagegen hilft nur mehrmals erzeugen und aussuchen. Kostet je Lauf den halben Text vom Kontingent.
Lebendiger sprechen- Ausdruck, Betonung aus dem Sternchen, 6 % straffer
Merts Wahl nach fuenf Hoerproben- "alles zusammen ist am besten aber minimal zu langsam gesprochen". Alle drei Hebel sind eingebaut. (1) STABILITAET auf STABIL_AUSDRUCK (0.0) statt neutral. Der Preis ist bekannt- die Stufe buext gelegentlich aus (falsche Betonung, selten ein verschlucktes Wort). Dagegen hilft Abhoeren, nicht ein Rueckschritt auf neutral — genau der war fuenf Tage lang die stille Antwort auf dieselbe Beschwerde. (2) ``*wort*`` WIRD ZUR BETONUNG. Bis dahin wurde der Marker fuer die Stimme schlicht geloescht- das Skript sagte also, welches Wort das wichtigste im Satz ist, und ausgerechnet der Sprecher erfuhr es nie. Jetzt schreibt stimme.mit_betonung() es fuer eleven_v3 gross (ab drei Buchstaben, sonst liest das Modell Buchstabenfolgen). Ein Marker, zwei Wirkungen- rot im Bild, betont im Ohr. Die Wortanzahl aendert sich nicht, Wortzuordnung und Szenenzeilen bleiben parallel. (3) TEMPO 1,06 ueber atempo, tonhoehenerhaltend. WICHTIG- angewendet ganz am Anfang von render(), BEVOR die Wortzeiten bestimmt werden. Wer die Stimme erst beim Abmischen strafft, bekommt ein Reel, in dem jedes Wort frueher faellt als sein Untertitel, und das sieht man erst im fertigen Video. WIEDER EIN STILLER REGLER- ElevenLabs nimmt "speed" in den Stimmeinstellungen an, und eleven_v3 ignoriert ihn. Gemessen mit festem seed- speed 0,7 und speed 1,2 liefern beide exakt 7,63 s. Zweiter Fall derselben Sorte an einem Tag (siehe Stabilitaet). MERKSATZ- bei diesem Anbieter gilt ein Regler erst als wirksam, wenn eine Messung ihn bestaetigt. DER TEXT IST DER STAERKSTE HEBEL und liegt beim Autor- kurze Saetze, Auslassungspunkte, eine Frage mittendrin, ``*wort*`` gezielt, Regie mit Haltung ([curious] am Haken). Steht als eigener Abschnitt in SKRIPT.md.
Der Ausdrucks-Regler hatte seit dem 14.08. keine Wirkung — v3 kennt drei Stufen
Merts Befund am 2026-08-19- "die stimme spricht mir zu monoton, zu wenig gefuehle, nicht sympathisch genug". Derselbe Satz wie am 14.08., und dazwischen war der Regler eigens dafuer verstellt worden. NACHGEMESSEN mit festem seed- eleven_v3 nimmt nur 0.0 (Ausdruck), 0.5 (neutral) und 1.0 (streng). Zwischenwerte werden STILL auf die naechste Stufe gerundet. 0.30 und 0.50 liefern Aufnahmen exakt gleicher Laenge (149.673 Bytes), 0.0 und 1.0 jeweils andere. Die Senkung von 0.45 auf 0.30 hat also nichts getan — beide runden auf 0.5, und der Kommentar daneben erklaerte ausfuehrlich eine Wirkung, die es nie gab. Genau die Fehlerklasse, vor der die Projektanweisung warnt- kein Fehler, kein rotes Feld, nur ein Regler, der ins Leere greift. EINGEBAUT- stimme.STABIL_AUSDRUCK / STABIL_NEUTRAL / STABIL_STRENG stehen jetzt als Namen im Code, die Vorgabe ist der ehrliche Wert 0.5. Wer einen Zwischenwert hinschreibt, sieht sofort, dass es ihn nicht gibt. ZUR AUSWAHL LIEGEN drei Hebel als Hoerprobe bereit (uploads/_stimmproben/gefuehl/)- der Regler auf Ausdruck, zusaetzliche Regie-Marken, und ein anders GESCHRIEBENER Text (kurze Saetze, Auslassungspunkte, Grossschreibung als Betonung). Gewinnt der Satzbau, gehoert die Regel in skript.py und wirkt in jedem kuenftigen Reel.
Zischlaute- eine breite Senke bei 8,5 kHz statt zweier schmaler
Runde 2 nach Merts "das einzige was noch stoert sind die fs". Ein S wiegt zwischen 5,5 und 8,5 kHz, ein F hoeher und breiter (9-14 kHz) — der EQ aus Runde 1 nahm davon gemessen 2 %. Sechs Aufbauten, gemessen als Minderung der S- und F-Spitzen gegen die rohe Aufnahme- Runde-1-EQ S-21/F-2 · zweite Senke bei 11 kHz S-32/F-27 · Hoehen-Dach ab 9 kHz S-19/F-34 · EQ+Regler ueber 8,5 kHz S-6/F-70 · breiter gezogen S-16/F-18 · EQ+De-Esser S-35/F-18. MERTS WAHL WIEDER NICHT DER BESTE MESSWERT ("breiter gezogen ist am besten")- drei Oktaven um 8,5 kHz decken S und F mit EINER Bewegung ab. Zwei getrennte Senken nehmen mehr weg, hinterlassen aber eine Delle dazwischen; der Stimme fehlt dann etwas, ohne dass man sagen kann was. EINGEBAUT als bau.STIMME_KLANG = equalizer=f=8500:width_type=o:width=3:g=-7, ganz vorne in der Sprecherkette. Gilt ab sofort fuer jedes Reel.
Zischlaute- Merts fester EQ gewinnt gegen jeden gemessenen De-Esser
Merts Beobachtung am fertigen Reel (2026-08-19)- "s und t werden stark gehoert, so ein stoerendes Geraeusch". Sieben Fassungen desselben Satzes wurden in der Cloud gerechnet und gemessen (Anteil im Zischband an der Gesamtenergie, 99. Perzentil)- unbehandelt 56,1 % · De-Esser leicht/mittel/ stark 50,5/41,3/37,2 % · Mehrband sanft 23,1 % · Mehrband stark 32,2 % · fester EQ 46,7 %. MERT WAEHLT DEN SCHLECHTESTEN MESSWERT, und zwar bewusst- "tatsaechlich ist der feste eq am besten". Die dynamischen Fassungen greifen in die Huellkurve ein und nehmen der Stimme mit der Zischspitze auch ein Stueck Deutlichkeit. Der EQ nimmt weniger weg, aber immer gleich viel — und das hoert man nicht als Eingriff. MERKSATZ FUER ALLES WEITERE- die Messung sagt, WIE VIEL weg ist, nicht ob es besser klingt. Wer hier nachdreht, laesst Mert hoeren statt auf die Prozente zu schauen. EINGEBAUT als bau.STIMME_KLANG (equalizer=f=7000:width_type=o:width=2:g=-6), ganz vorne in der Sprecherkette — vor apad und vor dem asplit, damit auch die Steuerspur fuers Ducking dieselbe Stimme hoert. Abschaltbar ueber _tonspur(entzischen=False). probe_ton.py bestaetigt alle Graphen. OFFEN- das F stoert weiter ("das einzige was noch stoert sind die fs"). Es liegt hoeher als das S, rund 9-14 kHz, und der EQ bei 7 kHz nimmt davon gemessen nur 2 %. Runde 2 mit sechs Aufbauten liegt zum Anhoeren bereit (uploads/_stimmproben/, Dateien 0_ bis 5_). NEBENBEI- der ffmpeg-Hook blockt auch "ffmpeg -h filter=…", also den reinen Hilfetext, der nichts rechnet. Kein Umgehen, nur gemeldet.
Stimmwerkstatt- Bibliothek zuerst, Entwurf zweitens, Merts Stimme moeglich
Merts Auftrag am 2026-08-19- "schau ob wir ueber ElevenLabs eine natuerlichere Stimme finden bzw. erzeugen koennen ... wenn das auch nicht klappt, schau ob es moeglich ist meine Stimme zu nutzen". WAS DER ZUGANG HERGIBT (nachgesehen, nicht geraten)- Stufe Starter, aktiv. Instant Voice Cloning ist FREIGESCHALTET, professionelles Klonen nicht (das braucht Creator). Stimmentwurf per Beschreibung geht ebenfalls. Bestes Modell fuer Deutsch bleibt eleven_v3 — es gibt nichts Neueres. NEUES WERKZEUG formate/vox/stimmwerkstatt.py mit fuenf Befehlen- bibliothek (suchen, gratis), holen (ins Konto legen), entwerfen (Stimme aus einer Beschreibung), behalten (Entwurf sichern), klonen (eigene Aufnahme), probe (mehrere Stimmen, gleicher Text, gleiche Einstellungen). BEWUSST GETRENNT von stimme.py- das ist der heisse Pfad, den mach.py bei jedem Reel aufruft. Herumprobieren an der Werkstatt soll den Produktionsweg nicht anfassen. REIHENFOLGE DER WEGE, nach Naturtreue- (1) Bibliothek, das sind Klone echter Sprecher, (2) eigene Aufnahme von Mert, (3) Entwurf per Beschreibung, der klingt am ehesten synthetisch, weil kein Mensch dahintersteht. GEMESSENE KOSTEN- ein Entwurf zieht die Zeichen des Probetextes EINMAL ab, obwohl drei Fassungen zurueckkommen (305 Zeichen fuer drei Stimmen). Eine Probe kostet wie normales Sprechen, bei eleven_v3 also halber Text. Klonen kostet nichts vom Kontingent, es belegt einen Stimmplatz (1 von 10 belegt). Der ganze Versuch hat 1.065 der 38.758 Monatszeichen gekostet. FALLE BEIM HINZUFUEGEN- eine Bibliotheksstimme braucht die Kennung des BESITZERS mit, und die laesst sich aus der Stimmkennung allein nicht nachschlagen. Deshalb gibt "bibliothek" gleich "besitzer/kennung" aus und "holen" nimmt genau das entgegen. LIEGT ZUM ANHOEREN- uploads/_stimmproben/ (ueber Syncthing auch auf dem PC), Erklaerung in 00_ANHOEREN.md.
Humor darf jetzt in den Sprechertext — nachgemessen an Simplicissimus2026-08-19
Merts Auftrag am 2026-08-19- "schau dir mal die Transkripte von Simplicissimus-Videos an und schau ob wir anhand deren Skript bei uns was anpassen können ... ich sage sogar wir haben etwas zu wenig Humor, vor allem leichter schwarzer Humor bzw. Sarkasmus wäre gut." VERMESSEN- drei Videos, 9,9 / 3,5 / 3,3 Mio Aufrufe, alle 6-10 min, also die kurzen und erfolgreichsten des Kanals (Transkripte über den youtube-transcript- Skill geholt). WAS UNSERE REGEL BLOCKIERT HAT- in SKRIPT.md stand seit dem 2026-08-11 "Humor- trocken, im BILD, und nie im Sprechertext". Abgeleitet aus EINER Vorlage, dem Cardboard-Cinema-Biberreel. Genau das, was Mert jetzt mehr will, war damit verboten. DER BEFUND- Simplicissimus erzählt auch keine Witze, der Sprecher bleibt Reporter. Der Humor sitzt trotzdem im gesprochenen Satz, aber nicht als Gag, sondern in WELCHE Tatsache gewählt und WOHIN sie gestellt wird. Die Grundregel ist also nicht widerlegt, sie war nur zu weit gefasst. SECHS BAUARTEN, alle jetzt dokumentiert- die nachgeschobene Tatsache ("er entscheidet sich für Craig David, von dem er noch nie was gehört hat"), das wertende Verb ("verballert"), das absurde letzte Listenglied ("Mafia-Mitglieder, Stripclubbesitzer, Drogendealer und eine Mormonenfamilie"), die zu genaue Zahl ("knapp 192 Mal gehustet"), das Amtswort für das Lächerliche ("Husteranalysen") und die entwertende Folge ("wurden zu britischen B-Promis"). WIR HATTEN ES SCHON, OHNE ES ZU BENENNEN- die stärkste Zeile des Rust-Reels ist eine davon- "Doch oben ist Feiertag, die Büros sind leer." BUDGET- zwei bis drei Stellen je Reel, die Pointe ist eine davon. Zusammen mit den Bilddetails höchstens rund fünf trockene Momente auf 45 Sekunden. ZWEITER FUND, HAKEN- Simplicissimus verrät im besten Video den AUSGANG ("er ist ein Betrüger") und öffnet dafür eine neue Frage ("aber wie?"). Das widerspricht unserer Regel "der Haken darf den Einsatz nennen, niemals den Ausgang" nur an der Oberfläche- beide sagen, dass nach dem Haken genau EINE Frage offen sein muss. Tauschen geht nur, wenn die Methode die eigentliche Geschichte ist (Betrug, Trick, Einbruch) - bei einer Entscheidung wie Petrow wäre es tödlich, seine Methode war nichts zu tun. DAS BMI-REEL IST DAS ERSTE SKRIPT GANZ OHNE SOLCHE STELLE- 18 Zeilen, alle ernst, dazu sechs Regieanweisungen wie [serious] und [whispers]. Die Länge war die gemessene Ursache für den Ausfall; die fehlende Trockenheit erklärt, warum es sich beim Hören zäh anfühlt. NICHT GEAENDERT- die Sperre bleibt, wo Menschen leiden (Radium, Petrow). Über Institutionen darf gespottet werden, über Opfer nicht.
Papier-3D bleibt, aber die Bewegung wird minimal — Aufbau ist aus2026-08-17
Merts Entscheidung am 2026-08-17, nachdem die Längensperre stand- "ich würde sagen 3d papierstil aber bewegung so minimal wie nur möglich, keine aufbau der szene oder ähnliches. Nur eine dezente bewegung sodass das bild zum leben erweckt. Weil die video clips waren offensichtlich ki generiert." WAS SICH GEÄNDERT HAT- aufbau_standard bei papier3d steht auf False (war True), und beide Drift-Vorlagen (BEWEGUNG und BEWEGUNG_3D in prompts.py) verlangen jetzt ausdrücklich die kleinste Bewegung, die noch lebendig wirkt. WARUM DIE ANSAGE PRÜFBAR FORMULIERT IST- im Auftrag steht "a still frame from the middle of the clip is nearly indistinguishable from the first frame". Ein Adjektiv wie "subtle" stand schon am 2026-08-02 drin und hat nicht gereicht; das Modell legt "small" gegen die Bildbreite aus. Eine Probe, die man am fertigen Clip nachstellen kann, hält besser als ein Wunsch. DRITTE STELLUNG DIESES SCHALTERS, erste aus diesem Grund. 2026-08-12 an, 2026-08-14 nur über 5 s — da ging es darum, ob der Aufbau in kurze Szenen PASST. Jetzt geht es darum, was man dem Clip ANSIEHT- ein Bild, das sich vor den Augen zusammensetzt, könnte keine Kamera aufnehmen. MITGEZOGEN- die zwei offenen Drehbücher mit "aufbau: true" (vox_kinotuer, vox_rust_papier3d). Bei beiden ist der betroffene Clip noch nicht erzeugt, es geht also nichts verloren. vox_bmi bleibt unangetastet (fertiges Video). NEBENWIRKUNG, angenehm- ohne Aufbau bestellt der Flow-Bot 4-Sekunden-Clips statt 10, also 7 statt 15 Tokens je bewegter Szene. NACHGEZOGEN AM SELBEN TAG, auf Merts "mach die voreinstellung auf papier3d und akte 03 umstellen"- STIL_STANDARD steht jetzt auf "papier3d". Vorher blieb die Voreinstellung auf Collage, obwohl die Entscheidung für den Papier-Stil schon am 2026-08-12 gefallen war; prompt kam das nächste Reel im alten Stil heraus ("außerdem wurde noch der alte stil von bild erstellt"). Eine Entscheidung, die nur in EINER Datei steht, ist keine Entscheidung, sondern eine Bitte. ZWEI SPERREN MUSSTEN DAFÜR VORHER WEG- (1) hintergrund und palette sind bei papier3d jetzt PFLICHT und werden in prompts.pruefe laut eingefordert (mach.py reicht den Stil dafür durch). Vorher fielen sie still auf den Stil-Standard zurück, und weil der für ALLE Szenen derselbe ist, hätte ein Drehbuch ohne die Angaben das ganze Reel vor dieselbe Wand gestellt — nicht kaputt, nur langweilig, also unsichtbar. Ausgenommen sind Beleg-Szenen und das Schlussbild, das die Felder gar nicht hat. (2) Die zehn Collage-Drehbücher in uploads/ haben jetzt ausdrücklich "stil: collage" im Kopf, sonst hätten sie sich beim Umlegen lautlos umgefärbt. AKTE 03 (uploads/vox_kinotuer) ist auf papier3d umgestellt- 13 Szenen mit Hintergrund, Zusatz und durchgehender Palette (Russ und Glut). Gegengeprüft am gebauten Auftrag- 14 von 14 Bildaufträgen tragen die Papier-Merkmale, 6 bewegte Szenen, kein einziger Aufbau, Cliplängen 3,2 bis 5,5 s.
Reel-Länge ist eine SPERRE bei 60 s — und der Titel muss ein Loch lassen2026-08-17
Anlass war Merts Verdacht am 2026-08-15- das neue BMI-Reel macht kaum Aufrufe, also sei es "shadowbanned, weil es als KI-Inhalt gekennzeichnet wurde", und der neue 3D-Papierstil sehe mehr nach KI aus als die flache Collage. WIDERLEGT, mit Zahlen. Das Video ist öffentlich, fertig verarbeitet, ohne Ablehnung und ohne Ländersperre; /shorts/<id> läuft ohne Umleitung, YouTube führt es also als Short. Die KI-Kennzeichnung setzen wir gar nicht — youtube_hochladen.py kennt das Feld containsSyntheticMedia nicht. AM 2026-08-18 von Mert im Studio nachgesehen und mit Bildschirmfotos belegt- unter "AI use" ist WEDER Ja NOCH Nein angekreuzt, die Frage ist unbeantwortet. Es gibt also keinen KI-Hinweis am Video, weder von uns noch von Hand. Die Shadowban-These ist damit endgueltig vom Tisch. Und der 36-Minuten-Midgley (34 Aufrufe, 6,7 % gesehen), den Mert mitgezählt hatte, ist kein Short- Langform im Feed gibt es nicht. DIE ECHTE URSACHE IST DIE LÄNGE. Aufrufe am Upload-Tag- Petrow 37,8 s → 704 · Radium 49,6 s → 745 · Rust 63,5 s → 1.484 · BMI 91,8 s → 77 nach zehn Stunden. Faktor 20. Der Algorithmus misst den ANTEIL, den die Leute sehen; Rust kam auf 132 % (mehrfach angesehen), auf 96 Sekunden ist das unmöglich. WARUM ES PASSIEREN KONNTE- die 35-55-s-Regel stand seit dem 2026-08-10 im Code, aber nur als WARNUNG unter fünfzehn Warnungen. Das BMI-Skript hatte 1.371 Zeichen bei einem Richtwert von 715, und niemand hat es gestoppt. Seit 2026-08-17 ist es ein FEHLER- pruefe(text, grenze_sekunden=...) in skript.py, scharf geschaltet in formate/vox/mach.py, also BEVOR Credits fliessen. WARUM DIE GRENZE NICHT IN DER VORGABE VON pruefe() STEHT- formate/archivdoku ruft dieselbe Prüfung für die Langform auf, wo zwanzig Minuten richtig sind. Stünde die Reel-Grenze in der Vorgabe, risse der nächste Grenzwert still die Langform mit. Vorgabe ist deshalb None, wer sperren will sagt es ausdrücklich. DIE GRENZE STAND EINEN HALBEN TAG AUF 60 und liegt seit dem 2026-08-17 auf 70. Merts erste Vorgabe war "unter 60 s erzwingen"; beim Nachprüfen an den eigenen Altdaten fiel auf, dass RUST daran gescheitert wäre — geschätzt 67 s, gemessen 63,5 s, und mit 3.125 Aufrufen das beste Video des Kanals. Eine Sperre, die das beste Ergebnis verbietet, misst das Falsche. Die Kante liegt zwischen 67 s (funktioniert, mehrfach angesehen) und 92 s (Totalausfall), nicht bei 60. Mert hat auf Nachfrage auf 70 entschieden. Gegengeprüft- Petrow 35 s, Songs 38 s, Radium 49 s, Kelsey 56 s und Rust 67 s gehen durch, BMI mit 97 s bleibt draußen. MERKE- eine Sperre gehört gegen die eigenen Altdaten gehalten, BEVOR sie scharf geschaltet wird. Hier war es ein halber Tag und ein Commit; beim nächsten Grenzwert kann es ein verworfenes Reel sein. TITEL- Merts Zusage lautete "Titel als Frage", die eigenen Zahlen haben das widerlegt- kein einziger der drei erfolgreichen Titel ist eine Frage. Alle drei sind Aussagen mit einem Loch ("Ein 18-Jähriger flog 1987 nach Moskau. Niemand schoss."). Der Flop ist der einzige VOLLSTÄNDIGE Satz- "Dein BMI kommt nicht aus der Medizin, sondern aus der Astronomie" stellt die Überraschung fest und löst sie im selben Atemzug auf. Regel deshalb- nach dem Titel muss eine Frage offen sein, die das Video beantwortet. Ein Fragezeichen ist erlaubt, aber die schwächere Bauart. Steht in formate/vox/SKILL.md. NICHT GEPRÜFT- ob der 3D-Papierstil auf die Haltequote wirkt. Die YouTube-Statistik hinkt drei Tage hinterher, die Abbruchkurve des BMI-Reels gibt es frühestens am 2026-08-18.
Ton bei Vox- Papier auf das, was wir selbst malen. Und ein dumpfer Schluss statt StilleTon
Aus der Vermessung eines Cardboard-Cinema-Reels, das Mert mitgebracht hat (2026-08-11). Gemessen, nicht geraten- 111 Geraeusche auf 79 s, aber nur 8 davon liegen auf einem Schnitt und 70 frei mitten in der Einstellung. Der Ton bebildert dort die HANDLUNG, nicht die Montage — ein Whoosh auf jeden Bildwechsel ist genau das, was dieses Video nicht tut. Uebertragbar ist das bei uns nicht über die Clips- ein Vox-Reel hat 11,7 Szenen, davon 1,8 bewegt, und darin driftet nur Rauch und Staub. Es gibt nichts anzufassen. Vertont wird deshalb, was ReelForge SELBST zeichnet und wessen Zeitpunkt es dadurch auf die Millisekunde kennt- Szenenwechsel und Kritzeleien. Material ist Papier, nicht Whoosh — Cardboard klingt nach Pappe, weil es aus Pappe ist; Aktenlage klingt nach Akte. Zweitens- die Pointe des Vorbilds kommt NICHT über Stille, obwohl es so klingt. Um den Schnitt ins Schwarze fallen Hoehen und Mitten weg (Hochband 38 auf 1), während der Bass steigt- eine Sekunde lang klingt es, als hielte man sich die Ohren zu. Stille ist ein Loch, Dumpfheit ist eine Handlung. Liegt bei uns auf der Schlusskarte. Beides einzeln abschaltbar (Regler "geraeusch" und "dumpf"), weil am 07.08. schon einmal ein Geraeusch komplett rausflog, obwohl nur der Pegel falsch war. NACHGEZOGEN am selben Tag- der erste Pegel (-28 dB) war unhoerbar, Merts Urteil am Testreel "ich hoere keine Soundeffekte". Die Musik liegt bei -10 dB, das Papier lag also 18 dB darunter. MESSBAR IST NICHT HOERBAR. Jetzt -18 dB und ein Schieberegler statt einer festen Zahl. Außerdem ATMO- ein durchgehender Klang unter bewegten Szenen (Typ "ton: motor" im Drehbuch, vier Typen im Repo). Der Einwand kam von Mert- ein Propeller klingt, Rauch nicht; "nichts anzufassen" galt nur für Einzelanschlaege. Kosten- einmalig zwei ElevenLabs-Geraeusche, die im Repo liegen; pro Reel null. Code- formate/vox/geraeusch.py, bau.DUMPF, probe_ton.py.
Reels zurück auf 35-55 s — die Laengenregel war falsch begruendet2026-08-10
Merts Urteil zum fertigen 105-Sekunden-Reel (2026-08-10)- "ich versteh die story einfach nicht, ich als zuschauer versteh kaum worum es geht ... die schnitte sind manchmal zu schnell ... zu viel storytelling und zu wenig offene fragen oder ein bezug zum zuschauer." DIE LAENGENREGEL WAR DER GRÖSSTE EINZELFEHLER. Am 2026-08-08 auf 60-90 s gesetzt, weil TikToks Creator Rewards erst ab 60 Sekunden zahlen. Uebersehen wurde, dass dieselben Rewards 10.000 FOLLOWER und 100.000 Aufrufe in 30 Tagen verlangen. Der Kanal hat ZWEI Abonnenten. Die Regel optimierte also auf einen Zustand, der Jahre entfernt ist, und bezahlte mit genau der Kennzahl, die einen dorthin bringt. GEMESSEN AM EIGENEN KANAL (aktenlage_zahlen.py, 60 Tage)- Petrow 37,8 s ergab 72,6 % gesehen und einen Abonnenten, Radium 49,6 s ergab 59,6 % und keinen. Zwoelf Sekunden mehr kosteten dreizehn Prozentpunkte. Der Algorithmus misst nicht die Laenge, sondern den ANTEIL. JETZT- 455-715 Zeichen (35-55 s), 12-18 Zeilen, Warnung ab 65 s. Die drei alten Reels liegen damit wieder innerhalb der Regel. DER ZWEITE FEHLER, und der ist erzaehlerisch- ich habe EINSATZ und AUSGANG verwechselt. Fassung 1 nannte in Zeile 1 den Einsatz und in Zeile 3 schon den Ausgang; danach war nichts mehr offen. Fassung 2 schob den Ausgang nach hinten und nahm dabei den EINSATZ mit- 75 Sekunden lang sah man jemandem beim Aktenschieben zu, bevor irgendwo stand, worum es geht. Beides falsch, und zwar gegenlaeufig. Richtig- Einsatz in Sekunde eins, Ausgang am Ende. DIE SCHNITTE- die Taktvorgaben stammen vom Phantom-Reel (12 Szenen, 58 s, rund 22 Einstellungen). Bei 27 Szenen auf 105 s ergaben dieselben Werte rund 50 Schnitte. Nicht der Takt war falsch, sondern die Szenenzahl; mit 15 Szenen liegt man wieder bei rund drei Sekunden je Szene. PROVOKANTE JA/NEIN-FRAGEN SIND JETZT ERLAUBT. Merts Vorschlag "Hat diese Frau tausende Kinder gerettet, indem sie nichts tat?" waere an der eigenen Regel gescheitert (nur W-Fragen im Haken). Die Regel war zu grob- schlecht ist die Frage nach dem WISSEN des Zuschauers ("Wusstest du …?"), gut ist eine Frage, die eine unglaubliche BEHAUPTUNG aufstellt. Das Paradox sieht kein Programm, also Warnung statt Fehler. ERGEBNIS- dritte Fassung, 56,1 s, 15 Szenen, kein einziges neues Bild noetig. WAS DIE KALTLESE NICHT KANN, und das ist die Lehre für das Werkzeug- sie hat die zweite Fassung BESTANDEN. Verstanden hat der Leser sie; wissen wollte niemand, wie es weitergeht. Sie misst Verstaendlichkeit, nicht Spannung, und ein LESER hat den Text vor sich, während der Zuschauer ihn einmal hoert.
Verstaendlichkeit- was der Autor kennt, kennt der Zuschauer nicht2026-08-10
Drei Befunde von Mert am fertigen AKTE-01-Reel (2026-08-10), alle drei in Code oder Regel gegossen — und alle drei Auspraegungen DESSELBEN Fehlers- der Autor haelt für allgemein bekannt, was er selbst gerade gelernt hat. (1) "keiner weiss was plazenta heißt, das darf in zukunft nicht erneut passieren." sprechtext.py hat jetzt eine Fachwortliste und bricht ab. NACHGESCHAERFT von Mert am selben Tag- "fachwoerter duerfen vorkommen aber gezielt genutzt wenn man etwas erklären moechte". Verboten ist also nicht das Wort, sondern das UNERKLAERTE Wort; steht direkt dahinter eine Erklärung (Beistrich, Gedankenstrich, Klammer, mindestens drei Woerter), geht es durch. Erkennt die Maschine die Erklärung im Satz nicht, erkennt der Hoerer sie auch nicht — das ist kein Fehlalarm zum Wegdruecken. (2) EIN ALTER MARKENNAME IST KEIN WIEDERERKENNUNGSWERT. Ich wollte "Contergan" ins Skript nehmen mit der Begruendung "das kennt in Deutschland jeder". Merts Antwort- "ich kenne contergan zb nicht." Damit ist die Annahme von der Zielgruppe selbst widerlegt- der Kanal lebt zu 97 % vom Shorts-Feed, das Publikum ist jung, und ein Markenname von 1961 ist dort kein Anker, sondern noch ein unbekanntes Wort. Getarnter als ein Fachwort- bei dem merkt man selbst, dass es Fachsprache ist, einen Eigennamen haelt man für Allgemeinwissen. Regel und Prueffrage in SKRIPT.md. (3) "das skript hat keinen schoenen roten faden, es springt zu schnell von fakten zu fakten und hat wenig spannung." skript.py misst jetzt die Faktendichte. GEMESSEN statt geraten- Petrow 25 %, Radium und Phantom je 33 % (tragen) gegen Midgley und Kelsey je 40 % (beide verworfen). Warnung ab einem Drittel. DIE URSACHE WAR ABER EINE ANDERE, und die Zahl ist nur ihr Symptom- das Skript verschenkte die AUFLOESUNG in Zeile 3 ("eine Frau, die sechsmal nein sagt"). Danach können 22 Zeilen nur noch bestaetigen, was feststeht. Neu geschrieben steht sie in Zeile 24, der Druck auf Kelsey läuft über sechs Zeilen statt einer, Faktendichte 22 %. WAS DABEI AUFFIEL- die Kaltlese-Probe hatte die ERSTE Fassung BESTANDEN. Verstanden hat sie jeder; wissen wollte niemand, wie es weitergeht. Die Probe misst Verstaendlichkeit, nicht Spannung, und das ist keine Schwaeche, die man ihr austreiben kann. Beides braucht seine eigene Prüfung. (4) "der abschluss mit nächste akte und abbonnieren ist nicht sichtbar genug." Aus dem weichen Verlauf wurde eine fast deckende Karte mit gerissener Oberkante, groesserem Titel und der Abo-Zeile als rotem Stempelrahmen — dieselbe Sprache wie die Kanalmarke am Anfang.
AKTE 01 steht — und der Weg dahin hat sechs eigene Fehler ausgeworfen2026-08-10
Fertig am 2026-08-10- uploads/vox_kelsey/REEL.mp4, 98,7 s, 25 Szenen, 1080x1920. Frances Kelsey, FDA, 1960/61 (Contergan). Erstes Reel mit Kanalmarke, Schlusskarte, echten Belegen und Quellenregister. DIE LAUFZEIT IST DER BEWEIS, nicht das Hinsehen- Sprecher 95,5 s plus Nachklang 0,8 plus Nachlauf 2,4 ergibt 98,7. Ein Reel ohne Schlusskarte waere 96,3 lang. So lässt sich auf dem Pi prüfen, was man dort nicht ansehen kann. ZWEI ECHTE BELEGE aus derselben gemeinfreien Aufnahme (Preisverleihung 07.08.1962, Werk der US-Bundesregierung)- Szene 8 ihr Portraet, Szene 23 die ganze Szene mit Kennedy. Vorher stand an beiden Stellen ein erfundenes Gesicht, während der Sprecher ihren Namen sagt. ELF ZAHLEN, ELF BELEGE. Der Quellenblock für die Videobeschreibung faellt aus quellen.yaml ab (fakten --block). WAS DER WEG ZUTAGE GEFOERDERT HAT — sechs Fehler in frisch gebautem Code, alle am echten Objekt und keiner in der Theorie- (1) tpad hielt das letzte Bild fest 2 s; mit der Schlusskarte war die Bildspur zu kurz. (2) apad verlaengerte die Stimme um einen FESTEN Betrag, der Mix endet aber mit "duration=shortest" — Bild 98,70 s, Ton 96,24 s, Abbruch nach vier Minuten Rechenzeit. Gefangen von der Laengen-Gegenprobe in abmischen(), die genau dafür am 2026-07-30 eingebaut wurde. (3) material.pruefe mass die ROHE Belegdatei statt der behandelten und forderte dazu auf, das einzige echte Foto zu beschneiden. (4) _zielname liess bei Belegen den nah-Teil weg — ausgerechnet das echte Bild hatte keine Zielpunkte. (5) AGENT.md nannte die Zahl der Szenen statt der Auftraege. (6) abnahme haette den Beleg als "gehört nicht dazu" gemeldet. UND EIN FEHLER, DER KEINER WAR- der Bildauftrag verlangte für die bewegte Hakenszene einen ruhigen Hintergrund und bestellte im Stilblock zugleich Landkarten und rote Faeden. Das Modell hat geliefert, was dastand. DAS AUSROLLEN WAR DER TEUERSTE EINZELFEHLER- das erste fertige Reel lief durch render:v45 und hatte KEINE der drei Neuerungen drin, weil der Cloud-Job den Code aus dem Abbild nimmt, nicht aus dem Ordner. Kostete einen kompletten Durchlauf. Steht als Aufgabe im Manifest und wurde trotzdem uebersehen; deshalb hier noch einmal- wer am Renderweg etwas ändert, rollt aus, BEVOR er baut.
Die Kaltlese-Probe ist eine Sperre, keine Bitte mehr2026-08-10
Merts Ansage am 2026-08-10- "die kaltlese sollte teil des automatismus sein bevor du mir den offiziellen auftrag gibst". WAS FALSCH WAR- die ganze Maschinerie stand seit dem 2026-08-02 bereit (kette.txt, frage, pruefe, Fingerabdruck gegen veraltete Kopien) und war trotzdem folgenlos, weil sie NIEMAND ERZWANG. Genau der Zustand, den der Dateikopf von kaltlese.py selbst als Ursache benennt- "es gab eine laute automatische Prüfung für Laenge und keine einzige für Verstaendlichkeit, die laute gewinnt immer". Ein drittes Dokument haette daran nichts geändert. JETZT STEHT SIE IM WEG- mach.py bricht ab, bevor es die Kosten auch nur NENNT, wenn keine bestandene Probe zum AKTUELLEN Skript vorliegt (kaltlese.bestanden, Ergebnis in .kaltlese_ergebnis.json mit Fingerabdruck). Wird danach eine Zeile geändert, verfaellt sie. DER LESER IST AUSTAUSCHBAR, DIE SPERRE NICHT- "kaltlese lesen" schickt GENAU den Inhalt von kaltlese.md an ein frisches Modell und prüft die Antwort. Ohne ANTHROPIC_API_KEY geht derselbe Weg von Hand oder über einen Unteragenten. Bewusst über urllib statt über ein Paket- ein Eintrag in requirements.txt haette den Unterbau des Render-Abbilds ungueltig gemacht, also sechs Minuten Bau für eine Prüfung, die mit dem Rendern nichts zu tun hat. WARUM EIN KLEINES MODELL LIEST (Haiku, nicht das beste)- je faehiger das Modell, desto eher rekonstruiert es fehlende Glieder aus eigenem Wissen und meldet "verstanden", während der echte Zuschauer aussteigt. Der Auftrag verbietet das Ergaenzen zwar, aber ein Verbot ist schwaecher als ein Modell, das die Luecke gar nicht fuellen kann. SOFORT EINGEFAHREN, ZWEIMAL- (1) Der Kaltleser von AKTE 01 raetselte, ob Kelseys Weigerung überhaupt etwas bewirkt hat. Es fehlte der Satz, dass das Mittel in Amerika nie VERKAUFT wurde; ohne ihn liest sich ihr Nein als folgenlos und die Pointe faellt in sich zusammen. Eine Zeile mehr, zweiter Durchgang sauber. Mechanisch waeren beide Fassungen durchgegangen — alle sieben Kettenglieder kamen schon beim ersten Mal an. Gefunden hat es der FREITEXT, nicht die Wortprobe. (2) DER FEHLALARM, der beinahe teurer geworden waere- kette.txt war als Prosa geschrieben statt mit Alternativen ("Unterschrift der Zulassungsbehoerde"), der Leser schrieb "unterschreibt die Zulassung nicht". Derselbe Schritt, und der Vergleich meldete FEHLT, weil er Woerter EXAKT vergleicht. Das ist die teuerste Richtung eines Fehlalarms- er treibt dazu, ein funktionierendes Skript zu "reparieren". lade_kette warnt jetzt bei Zeilen ohne "|". OFFEN GESAGT- die Kette wurde NACH der Messung erweitert. Das ist nur zulaessig, weil jede ergaenzte Formulierung für sich begruendbar ist ("Zulassung" gehört offensichtlich zu diesem Schritt), nicht weil sie in der Antwort stand. Wer die Kette so lange anpasst, bis es passt, hat die Probe abgeschafft.
Abo-Grund, echte Belege, Quellenregister — drei Antworten auf EINE Messung2026-08-10
Gebaut 2026-08-10 auf Merts Auswahl, nachdem ich Vox und ReelForge auf Verbesserungen durchgesehen hatte. Ausloeser aller drei Punkte ist dieselbe Zahl- 2.021 Aufrufe, EIN Abonnent, bei guter Bindung (72,6 %). Die Leute schauen zu Ende und gehen. Es fehlte kein Bild, es fehlte ein Grund zu bleiben. MERTS EIGENE IDEE WAR ECHTES FOOTAGE — und die gab es schon. formate/archivdoku ist eine vollstaendige Reel-Art aus echtem Archivmaterial, die er am 2026-07-31 selbst beerdigt hat ("tote idee, das ist null catchy"). Das wurde ihm gesagt, und stattdessen die nie probierte Variante gebaut- echtes Material als ZUTAT in der Collage statt als eigenes Format. (1) KANALMARKE UND SCHLUSSKARTE (formate/vox/marke.py, neu). Kleiner Stempel oben links in den ersten 1,8 s und am Ende "NÄCHSTE AKTE- <Titel>" plus Kanalname. Gesteuert über drei freiwillige Zeilen im drehbuch.yaml (kanal, akte, naechste_akte), von dort über mach.py und wolke.py in die Cloud. WARUM DIE MARKE KEIN VORSPANN IST- ein halbsekuendiges Logo am Anfang waere der teuerste Fehler bei Kurzvideo. Die Marke liegt deshalb ÜBER dem laufenden Haken und kostet null Laufzeit. Die Schlusskarte kostet dagegen rund drei Sekunden (bau.abmischen bekommt nachlauf=2,4) — bewusst bezahlt- Bindung hat der Kanal gemessen schon, Abonnenten nicht. WO SIE SITZT- komplett oberhalb der 402-Pixel-Grenze, ab der YouTube Shorts unten selbst einblendet. Erste Fassung stand 250 px über dem Rand und waere auf YouTube ausgerechnet mit der Kanalzeile zugedeckt worden; am Standbild gesehen, nicht im fertigen Video. (2) ECHTE BELEGE (formate/vox/beleg.py, neu). Eine Szene mit "beleg: true" und "quelle:" bekommt KEINEN Bildauftrag- ihr Bild wird beschafft, nicht erfunden. Beim Rendern kommt es in den Papierschnitt-Look (Graustufe, 45-Grad-Halbtonraster, gerissene Kante, leicht schief, roter Akzent daneben gedruckt, gealtertes Papier). Erkannt wird es am Dateinamen ("05_beleg_midgley.jpg") — dieselbe Bauart wie der Einstiegspunkt der Archiv-Doku, aus demselben Grund- was NEBEN der Datei liegt, kann sich von ihr loesen, im Namen kann es das nicht. DAS ARGUMENT, DAS DEN AUSSCHLAG GAB- bis hierher wurde jedes Bild erfunden, auch das Gesicht eines real existierenden Menschen (das Midgley-Portraet). Das ist derselbe Fehler wie eine erfundene Jahreszahl im Bild, gegen die der Bildauftrag seit dem 2026-08-02 ausdruecklich absichert- das Bild widerspricht der Wirklichkeit, und bei einem Erklaerformat ist das ein Glaubwuerdigkeitsproblem. Der Kanal heißt Aktenlage und zeigte bis jetzt keine einzige echte Akte. GRENZE, UND SIE IST BEGRUENDET- hoechstens ein Drittel der Szenen. Darüber ist es wieder die Archiv-Doku, die Mert abgelehnt hat. prompts.pruefe und beleg.vorbereiten warnen beide. RECHTE- nur gemeinfrei. CC-BY verlangt Nennung, CC-BY-SA verlangt dieselbe Lizenz fuers Ergebnis (bei einem monetarisierten Video unbrauchbar). "quelle:" ist Pflicht, sonst bricht die Drehbuchpruefung ab- ohne Nachweis kann man einem falschen Rechteanspruch auf YouTube nicht fristgerecht widersprechen. SPART AUSSERDEM 40 Credits je ersetztem Bild (bestellen.kosten zählt Belege nicht mit, bestellen.bestelle bricht ab statt sie erzeugen zu lassen). (3) QUELLENREGISTER (formate/vox/fakten.py, neu). Liegt ein quellen.yaml neben dem Skript, prüft mach.py vor jeder Bestellung- jede Jahreszahl und jede Zahl im Skript braucht einen Beleg, sonst läuft nichts. Fehlt die Datei, bleibt es bei einem Hinweis — alles andere haette alle bestehenden Reels auf einen Schlag gesperrt. DIE BELEGE ZITIEREN WOERTLICH aus dem Skript statt Zeilennummern zu nennen. Eine Zeilennummer waere kuerzer und genau deshalb falsch- zwei Dateien, die zeilenweise zueinander passen müssen, laufen auseinander, sobald jemand einen Satz einfuegt. Am umgeschriebenen Midgley-Satz nachgestellt- der Pruefer meldet beides, das verwaiste Zitat UND die nun unbelegte Zahl. EHRLICHE GRENZE- das Werkzeug prüft die BUCHFUEHRUNG, nicht die Wahrheit. Kein Programm weiss, ob 1921 stimmt. Der Gewinn ist, dass "einmal nachschlagen" zur Bedingung wird statt zur guten Absicht — und der Quellenblock für die Videobeschreibung faellt nebenbei ab (alle Vorbilder haben einen). DIE ZAEHLUNG FAENGT BEI 01 AN (Merts Entscheidung am selben Tag, auf meinen Vorschlag hin). Die fünf vorhandenen Reels (Eiffel, Midgley, Petrow, Phantom, Radium) zählen NICHT mit- sie tragen keine Nummer im Bild, und eine Reihe, die für den Zuschauer bei 06 beginnt, wirft nur die Frage auf, wo die ersten fünf sind. Nachgeschnitten wird ohnehin nichts (Regel vom 2026-08-09, nur nach vorn). Form "AKTE 01", zweistellig — einstellig würde die Marke ab der zehnten Folge im Bild springen, weil sie links sitzt und nach rechts wächst. mach.py meldet eine abweichende Form und sieht außerdem in den Nachbarordnern nach, ob eine Nummer schon vergeben ist- zwei Reels mit "AKTE 03" faellt beim Bauen niemandem auf, sondern erst dem Zuschauer, der beide sieht. WAS NOCH NICHT GEPRÜFT IST- die drei Bausteine sind einzeln am Standbild nachgesehen (Marke, Schlusskarte, behandelter Beleg als PNG), die neue ffmpeg-Filterkette für die zwei Einblendungen aber noch NIE gelaufen. Auf dem Pi geht das nicht (Render-Sperre). Erster echter Beweis ist das nächste Reel; bis dahin gilt die Kette als unbewiesen, nicht als fertig.
Kanalseite auf Abonnenten eingestellt- Trailer, Versprechen, Stichwoerter2026-08-09
Am 2026-08-09 gesetzt, direkt nach der Messung (2.021 Aufrufe, EIN Abonnent). Merts Ansage- "dann lass den schritt machen". TRAILER FÜR NICHT-ABONNENTEN- der Petrow-Short (meistgesehen UND beste Bindung, 72,6 % der Laenge). Vorher lief bei einem Klick auf die Kanalseite gar nichts; der Besucher sah eine Liste und musste selbst wählen. Der Trailer uebernimmt genau den Moment, in dem jemand ueberlegt, ob er bleibt. BESCHREIBUNG- Merts Zeile bleibt oben stehen, darunter steht jetzt, WAS man bekommt und warum man abonnieren sollte. Vorher sagte sie nur, was der Kanal ist. STICHWOERTER- vorher keine. Damit fehlte YouTube der Anhaltspunkt, in welche Nachbarschaft der Kanal gehört. AM 2026-08-10 NACHGEZOGEN (Mert- "alles gute hinweise setze sie um")- BANNER (aktenlage_banner.py, neu). Die entscheidende Zahl- das Bild ist 2048x1152, ueberall sichtbar ist aber nur ein Streifen von 1235x338 in der MITTE. Auf dem Fernseher sieht man alles, auf dem Handy nur den Streifen. Wer den Kanalnamen ausserhalb setzt, hat ihn für die Mehrheit nicht gesetzt; das Skript bricht ab, wenn der Text nicht hineinpasst. Grundlage ist wie beim Vorschaubild ein Bild aus den Videos selbst. BESCHREIBUNG NEU GESCHRIEBEN. Merts alte Zeile "Geschichten die NIEMAND aufgeschrieben hat" ist raus, auf seine Ansage hin- zu Midgley gibt es ein Veritasium-Video mit 30 Mio. Aufrufen, die Behauptung war angreifbar. Jetzt "Geschichten, die man dir nie erzaehlt hat" — genauso stark und nicht widerlegbar. ZWEITE FASSUNG NACH VORBILDERN (Mert- "schau dir mal lieber an wie andere youtube kanaele beschreibungen aussehen"). Statt Ratgeber-Artikeln die Beschreibungen echter Kanaele über die Schnittstelle abgefragt (Simplicissimus 2,5 Mio, MrWissen2go Geschichte 1,5 Mio, Terra X History 1,4 Mio, Y-Kollektiv 1,2 Mio, ARTE 2,7 Mio). GEMEINSAMES MUSTER, alle fünf- (1) Der inhaltliche Teil ist KURZ, ein bis drei Sätze. Alles danach ist Organisation (Links, Impressum, Netiquette), nicht Werbung. (2) Direkte Anrede- "Du bist ein Geschichts-Nerd?", "Bei Terra X History bekommt Ihr", "Hier findet ihr". (3) Gesagt wird, WAS man bekommt, nicht wie toll es ist. Simplicissimus- "Schoen, verstaendlich, kritisch und fundiert. Wir machen Essays zu Fragen, die du dir noch nie, oder viel zu oft gestellt hast." (4) WER EINEN RHYTHMUS HAT, NENNT IHN- "Neue Folgen gibts jeden Montag!", "jeden Sonntag". Steht bei uns bewusst NICHT drin, solange Mert keinen zugesagt hat. (5) Geschaeftliche Kontaktadresse ist ueblich. Fehlt bei uns noch. Rausgeflogen ist dadurch die Zeile "manchmal als ganze Ermittlung über eine halbe Stunde" (Merts Urteil- "finde ich scheisse"). Kein Vorbild beschreibt seine Videolaengen; jetzt steht dort "Kurze Faelle, lange Recherchen." KOMMENTARE unter beiden Shorts gesetzt- ein Nachtrag zur Geschichte plus die Aufforderung zu abonnieren. ANHEFTEN MUSS MERT, die Schnittstelle kann das nicht. FEHLER DABEI, korrigiert- in der ersten Fassung stand "jede Woche einen Fall". Diesen Zeitplan hat Mert nie zugesagt; ein Versprechen, das der Kanal nicht haelt, ist schlimmer als keines. Jetzt steht dort "Hier liegen mehr solcher Akten". NOCH OFFEN- der Abo-Hinweis am Ende der Reels. Gehört in den Renderweg, lässt sich auf dem Pi aber nicht ansehen (kein Rendern) — deshalb zusammen mit dem nächsten Reel bauen und im selben Lauf prüfen, statt blind einzubauen.
GEMESSEN- 97 % kommen aus dem Shorts-Feed, 0,9 % aus der Suche2026-08-09
Erste echte Zahlen des Kanals (aktenlage_zahlen.py, neu am 2026-08-09; liest die YouTube-Analyse-Schnittstelle, Zeitraum 28 Tage, 2.021 Aufrufe). ANLASS WAR MERTS WIDERSPRUCH- "ich denke das sehr wenig leute blei im benzin suchen". Er hatte recht, und zwar deutlicher als gedacht. HERKUNFT DER AUFRUFE- Shorts-Feed 96,9 % · andere YouTube-Seite 1,4 % · SUCHE 0,9 % (19 Aufrufe) · Kanalseite 0,7 %. DIE SUCHBEGRIFFE SIND REINES RAUSCHEN- "monte polizei", "cobra kai edit", "horrorfilme", "lustige videos zum totlachen", "ronaldo edit 2008 skills". KEIN EINZIGER hat mit unseren Themen zu tun. Das sind Leute, die etwas anderes gesucht haben und im Shorts-Feed hier gelandet sind. WAS DARAUS FOLGT- Suchbegriffe im TITEL kaufen nichts. Der Titel gehört ganz dem Klickanreiz; die Begriffe stehen in Beschreibung, Stichwoertern und Untertiteln, wo sie nichts kosten. Für die Langform gilt das nur eingeschraenkt- 36 Minuten laufen nicht im Shorts-Feed, dort ist Suche und Vorschlag der einzige Weg. Erste Messung dazu fruehestens in ein bis zwei Wochen. DAS EIGENTLICHE PROBLEM STEHT WOANDERS- 2.021 Aufrufe ergaben EINEN Abonnenten (0,05 %). Die Zuschauerbindung ist gut (72,6 % bzw. 59,9 % der Laenge), die Leute schauen also zu Ende und gehen dann. Es fehlt ein Grund zu bleiben, nicht Reichweite. Das ist der nächste Hebel, nicht SEO. WAS DAS WERKZEUG NICHT KANN- Suchvolumen vorhersagen. YouTube veroeffentlicht keine echten Volumen; jede Zahl in einem SEO-Werkzeug ist geschaetzt. Wer vorab Themen vergleichen will, nimmt den Reiter "Recherche" im Studio (nur niedrig/mittel/hoch) oder Google Trends mit YouTube-Filter. TECHNIK- Recht yt-analytics.readonly (nur lesen) am 2026-08-09 dazugenommen, Mert hat sich neu angemeldet. Außerdem musste die Analytics-Schnittstelle im Google-Projekt beatfactory-497615 erst freigeschaltet werden (gcloud services enable youtubeanalytics.googleapis.com).
YouTube-Beschreibungen- kein KI-Hinweis, 10-12 Hashtags, Suchbegriffe nach vorn2026-08-09
Merts Ansage am 2026-08-09 nach dem Start des ersten Langvideos- "die KI raus" und "fünf Hashtags sind nicht zu wenig für YouTube". KEIN KI-HINWEIS MEHR- der Satz "Bilder und Sprecherstimme sind KI-erzeugt" ist aus allen drei Videos raus. Vertretbar, weil YouTubes Offenlegungspflicht auf REALISTISCHE Darstellungen zielt, die jemanden taeuschen können — unsere Bilder sind erkennbar Papiercollagen, und die Stimme ahmt niemanden nach. Wer es doch kennzeichnen will, nimmt den Schalter "verändertes Material" im Studio, nicht die Beschreibung. HASHTAGS 10-12 STATT 5- die 5er-Regel stammt von TikTok/Instagram und galt hier faelschlich mit. Laut YouTube-Hilfe werden Hashtags erst ab 60 ignoriert; über dem Titel erscheinen bis zu drei, also die staerksten nach vorn. NICHT geprüft ist, ob mehr Hashtags überhaupt etwas bringen — die Wirkung liegt bei Titel, den ersten ~160 Zeichen und den Untertiteln. Mehr als ein Dutzend waere Deko. SUCHBEGRIFFE IN DIE ERSTEN 160 ZEICHEN- vorher stand dort nur die Todesszene, "Blei im Benzin" und "Ozonschicht" kamen zwei Absaetze später. Kostet etwas Dramatik in der Beschreibung, die aber ohnehin niemand vor dem Klick liest — dafür sind Titel und Vorschaubild da. WERKZEUG- Skill "youtube-seo" (kostja94/marketing-skills, 2.5K Installationen, 871 Sterne, drei Sicherheitspruefungen bestanden, kein API-Schluessel) liegt jetzt in skills-lock.json. Kompakte Checkliste für Titel/Beschreibung/Tags. Für Kanal-ANALYSE gibt es nichts Brauchbares- die gefundenen Analyse-Skills liegen alle unter 500 Installationen oder haengen an einem kostenpflichtigen Fremddienst. Zahlen holt man besser direkt über die YouTube-Schnittstelle.
Erstes Langvideo veroeffentlicht — Titel, Vorschaubild, Untertitel2026-08-08
Am 2026-08-08 hochgeladen, geplant für Sonntag 2026-08-09 18-00 Uhr- "Er hat die ganze Welt vergiftet — und du traegst es bis heute in dir" (Video AMpF0dm4AWM, 36-02, 13 Kapitelmarken, 16 Stichwoerter). MERTS VORGABE- "titel und thumbnail müssen allgemein extrem anziehend sein und gerne auch uebertreibend". Umgesetzt mit einer Grenze, die keine Geschmacksfrage ist- jeder Satz auf Titel und Bild kommt im Video woertlich vor. Ein Versprechen, das nach einer Minute platzt, holt den Klick und verliert ihn wieder — und genau das misst YouTube. TITEL UND BILD SAGEN VERSCHIEDENES- die Zahl im Bild ("800 MILLIONEN IQ-PUNKTE WEG"), die Behauptung im Titel. Zweimal derselbe Satz verschenkt die halbe Fläche. VORSCHAUBILD AUS DEM FILM SELBST (formate/vox/langvorschaubild.py, neu)- kein eigens bestelltes Bild. Kostet nichts, und der Zuschauer bekommt beim Klicken genau das, was er gesehen hat. Regeln- Gesicht nicht ueberdecken (das Laecheln IST der Klickgrund), hoechstens vier Woerter, unten rechts frei für die Laufzeit-Einblendung, dunkler und kontrastreicher als das Original. UNTERTITEL BRAUCHEN "youtube.force-ssl"- das Recht "youtube" reicht NICHT, obwohl es größer klingt. Aufgefallen erst, als das Video schon oben lag. Scope in youtube_verbinden.py ergaenzt, Mert hat sich am selben Tag neu angemeldet, Spur hängt dran (Stand "serving"). Wichtig, weil die Langform bewusst KEINEN Text ins Bild brennt- ohne Untertiteldatei ist das Video über seinen gesprochenen Inhalt nicht auffindbar. OHNE ABSPANN- das Abschlussbild wurde für dieses Video nie bestellt, also endet es eine Sekunde nach dem letzten Wort. Folge- keine YouTube-Verweiskaesten, sie laegen über dem Schlusssatz. Neu rendern (rund 1 EUR, anderthalb Stunden) waere für ein Verweisziel, das es noch gar nicht gibt. Beim nächsten Langvideo von Anfang an mitbestellen. DER VERWEIS IN DEN SHORTS TRAEGT SICH SELBST NACH (aktenlage_verweis.py, cron am 9.8. alle 10 min zwischen 18 und 23 Uhr). Merts Frage- "kannst du das nicht automatisch mit dem job morgen machen". Wichtig- einen Job, an den man sich haengen könnte, gibt es NICHT — das Veroeffentlichen macht YouTube selbst, auf dem Pi läuft dafür nichts. Das Skript wartet deshalb nicht auf die Uhr, sondern fragt den ZUSTAND ab (privacyStatus == public) und darf beliebig oft laufen- steht der Link schon drin, tut es nichts. Ein Termin kann sich verschieben, eine Verarbeitung haengen; ein toter Link in den zwei meistgesehenen Videos des Kanals waere schlimmer als gar keiner.
Geld-Strategie: Langform verdient, Reels werben — und Reels gehen auf 60-90 s2026-08-08
Entschieden von Mert am 2026-08-08 nach einer Recherche zu Monetarisierung und Nische (Web + YouTube-Transkripte). DER BEFUND, DER ALLES ANDERE ERKLAERT- Kurzvideos zahlen fast nichts. YouTube Shorts bringen 0,01-0,15 $ je 1.000 Aufrufe. TikToks Creator Rewards zahlen überhaupt nur für Videos AB 60 SEKUNDEN (dazu 10.000 Follower und 100.000 Aufrufe in 30 Tagen). Das Geld liegt in der Langform- Doku/Geschichte bringt rund 5-12 $ je 1.000 Aufrufe, deutschsprachiges Publikum etwa die Haelfte davon. (1) REELS GEHEN AUF 60-90 SEKUNDEN. Bis dahin galten 20-25 s, später 30-43 s. Der alte Befund ("unter 25 s werden Reels am haeufigsten zu Ende gesehen") ist NICHT widerlegt, sondern ueberstimmt- ein 40-Sekunden-Reel kann viral gehen und trotzdem null einbringen. Bezahlter Preis- weniger Durchsichten je Video. Umgesetzt in SKRIPT.md (Drei-Boegen-Aufbau statt einem) und skript.py (780-1.170 Zeichen, 24-36 Zeilen, Warnung ab 100 s). Wer bewusst nur Reichweite will, darf weiter kuerzer — dann ohne Erwartung an Einnahmen. NUR NACH VORN, NICHTS WIRD NACHGEZOGEN (Merts Klarstellung 2026-08-09- "es sollen keine jetzigen Videos ueberarbeitet werden, sondern nur für die Zukunft Vorgaben gemacht werden"). Die vorhandenen Reels — Eiffel, Midgley, Petrow, Phantom, Radium, Songs — bleiben wie sie sind- nicht nachschneiden, nicht neu vertonen, nicht ersetzen. Auch nicht "kurz mal auf 60 s bringen". Der Pruefer meldet bei alten Skripten eine Laengenwarnung; die ist richtig und trotzdem folgenlos. Aus demselben Grund werden aus dem ersten Langvideo VORERST KEINE neuen Reels geschnitten — der Vorschlag lag auf dem Tisch und wurde nicht angenommen. (2) REELS ENTSTEHEN AUS DER LANGFORM, nicht daneben. Aus einem 20-Minuten-Skript fallen drei bis fünf Reels, deren Recherche schon bezahlt ist; jedes verweist am Ende auf das lange Video. Damit ist die Reihenfolge festgelegt- erst die Langform, dann die Reels. Auf YouTube laufen dieselben 60-90-s-Stuecke als Shorts und fuehren zum Langvideo. (3) NISCHE BLEIBT, WIRD ABER SCHAERFER GEFASST- Wissenschafts-, Technik- und Ermittlungsgeschichten mit einem menschlichen Fehler im Zentrum (Midgley, Radium-Maedchen, Petrow, Phantom). NICHT reines True Crime- der deutsche Markt ist dort voll (Crimify, ZDFinfo, Wahre Verbrechen) und Gewaltthemen druecken den Werbepreis. Das Vorbild ist belegt- der Kanal "Fern" (~5 Mio. Abos in gut zwei Jahren, erzaehlte Einzelfall-Dokus) stammt von denselben Gruendern wie Simplicissimus. Simplicissimus macht Zeitgeschehen mit grossem Team; die erzaehlte Einzelfall-Doku in dieser Bauart macht auf Deutsch niemand — das ist die Luecke. (4) AKTUELLE THEMEN SIND ERLAUBT, ABER IN DERSELBEN NISCHE (Merts Zusatz). Sie ziehen Aufmerksamkeit, kosten aber den Vorteil der Nische- Geschichte veraltet nicht, Videos von vor drei Jahren bringen noch Aufrufe. Faustregel- der Rahmen bleibt "wie es dazu kam", das aktuelle Ereignis ist der Anlass, nicht der Inhalt. AUSGEBAUT AM 2026-08-09 ZUR ARBEITSTEILUNG DER FORMATE. Merts Idee- "die Long Form Videos werden hauptsaechlich Storys aus alter Zeit die man noch in Zukunft anschauen wird und die Reels werden hauptsaechlich News von der heutigen Zeit." Der erste Teil ist uebernommen, der zweite abgewandelt, und Mert hat der Abwandlung zugestimmt ("deine ist gut"). UEBERNOMMEN- Langvideo = zeitlose Geschichten (verdient über Jahre, der Rueckenkatalog traegt), Reel = darf am Tagesgeschehen haengen (ist nach zwei Tagen ohnehin tot, Vergaengliches ist dort billig). Die Zuordnung Haltbarkeit zu Format ist richtig gedacht. ABGEWANDELT- das Reel erzaehlt KEINE Nachricht, es geht durch die Schlagzeile hinein und holt die Geschichte aus dem Archiv- nicht "das ist gestern passiert", sondern "das ist gestern passiert, und es ist schon einmal passiert, 1937, und das hat man daraus gelernt". WARUM NICHT EINFACH NEWS- der Algorithmus lernt pro KONTO, nicht pro Format. Dieselbe Ueberlegung, aus der hier keine Musikvideos laufen- mischt man zwei Sorten, lernt er gar nichts. Nachrichten-Reels bringen Nachrichten-Publikum, und das klickt keine 36-Minuten-Doku über einen Chemiker aus den 1920ern. Die Reichweite kaeme an, nur nicht dort, wo sie hin soll — und der einzige Zweck der Reels ist dieser Fluss ins Langvideo. Dazu- News heißt Tempo statt Sorgfalt und ein falscher Satz beschaedigt einen Kanal, dessen Kapital Verlaesslichkeit ist; News-Reels sind das ueberfuellteste Format überhaupt; und 90 Sekunden sind für eine Nachricht langsam. KEINE QUOTE (Merts Nachschaerfung am selben Tag)- hier stand kurz "etwa jedes dritte Reel". Sein Einwand- "am besten nicht fest jedes dritte Reel, sondern je nachdem ob es etwas Aktuelles gibt, wo man eine gute Story zu erzaehlen kann." Richtig, und die Quote ist raus. Eine Quote zwingt dazu, einen Aufhaenger zu suchen, auch wenn keiner da ist — dann biegt man sich eine schwache Verbindung zurecht, und genau daran merkt der Zuschauer, dass er verkauft wird. DER PRUEFSTEIN, DER DIE QUOTE ERSETZT- die Schlagzeile zudecken. Bleibt ohne den aktuellen Bezug immer noch eine Geschichte übrig, die man erzaehlen würde? Ja = bauen. Nein = News-Reel mit historischer Verzierung, gehört nicht auf diesen Kanal. Das erledigt auch die Sorge hinter der Quote- ein aktueller Fall mit tragfaehiger Geschichte dahinter ist selten, die Reels bleiben also von selbst ueberwiegend zeitlos, ohne dass jemand mitzaehlt. Echte News gehören auf ein EIGENES Konto, nicht auf Aktenlage — solange der Kanal keine 1.000 Abonnenten hat, ist das aber doppelte Arbeit ohne Gegenwert. Ausgeschrieben in formate/vox/SKRIPT.md ("Themenwahl"). (5) HOCH-CPM-NISCHEN (Finanzen, Recht, Software) WURDEN GEPRÜFT UND VERWORFEN. 15-50 $ je 1.000 klingt gut, ist aber genau das Muster, das YouTube am haertesten trifft- KI-Stimme plus Finanzratschlag plus kein echter Absender. WAS DIE POLITIK-RECHERCHE ERGEBEN HAT- YouTubes Regel "Inauthentic Content" (Juli 2025, im Juli 2026 nachgeschaerft) verbietet nicht KI, sondern Fliessband ohne Wert- gleiche Schablone täglich neu befuellt, erfundene Person als Moderator, fremdes Material nur umsortiert. Aktenlage ist sauber (eigene Recherche, eigenes Skript, Marke statt erfundener Person). Vollautomatik bleibt deshalb ausgeschlossen- die Maschine uebernimmt Produktion, nicht Urteil.
YouTube-Anbindung für Aktenlage — abgeschaut bei beatfactory2026-08-07
Gebaut 2026-08-07 auf Merts Auftrag "schau wie beatfactory mit YouTube redet und verknuepf das mit Aktenlage". WIE ES BEI BEATFACTORY LÄUFT- Google-Cloud-Projekt beatfactory-497615 haelt den Zugangsschluessel (client_secret.json), die einmalige Anmeldung liegt als youtube_token.json daneben, und beat_generator.py frischt sie bei jedem Lauf selbst auf. Rechte- youtube.upload + youtube. Läuft seit Monaten, drei Videos am Tag auf "Valvet Beats", alle oeffentlich. WAS HIER NEU IST- youtube_verbinden.py (einmalige Anmeldung, schreibt aktenlage_youtube_token.json) und youtube_hochladen.py (Hochladen, Kategorie Bildung, Sprache Deutsch, standardmaessig NICHT oeffentlich). DERSELBE ZUGANGSSCHLUESSEL, GETRENNTE ANMELDUNG- das Google-Projekt wird mitbenutzt, der Kanal nicht. Grund- ein frisches Projekt müsste bei Google erst durch die Prüfung, bis dahin sind Uploads gesperrt; beatfactory-497615 ist nachweislich durch (die Videos dort sind oeffentlich). Was man sich einhandelt- beide Kanaele teilen sich das Tageskontingent von 10.000 Einheiten. Ein Upload kostet 1.600, beatfactory verbraucht rund 5.000 am Tag. Für ein Reel alle zwei Tage reicht das dreifach; wer täglich mehr als zwei hochlaedt, läuft rein. SCHUTZ GEGEN DEN FALSCHEN KANAL- auf dem Pi liegen jetzt zwei YouTube-Anmeldungen. youtube_hochladen.py fragt vor jedem Upload den Kanalnamen ab und bricht ab, wenn nicht "Aktenlage" drinsteht. Ein Reel auf dem Beat-Kanal faellt sonst erst auf, wenn es oeffentlich ist. ANMELDUNG GEHT NUR MIT MERT- der Pi hat keinen Bildschirm, und Google leitet nach dem Login auf localhost zurück (= der Rechner mit dem Browser, nicht der Pi). Das Skript lässt deshalb die Adresse aus der Adresszeile zurueckkopieren; mit --adresse/--code lässt sich das auf zwei Schritte aufteilen (fuers Handy). ERLEDIGT AM 2026-08-08- verbunden ist der Kanal "Die Aktenlage" (UC59TfweCIGW9YlptJslzmNA), Rechte youtube.upload + youtube. IM AUGE BEHALTEN- Google zeigt beim Anmelden "Google hasn t verified this app". Das heißt nur, dass die App nie zur Prüfung eingereicht wurde. Steht sie bei Google auf "Test" statt "In Produktion", verfaellt die Anmeldung nach 7 TAGEN und muss neu gemacht werden. Beweis dafür oder dagegen gibt es erst durch Warten- läuft "youtube_hochladen.py --stand" nach dem 2026-08-15 noch, ist alles gut; kommt "invalid_grant", im Google-Cloud-Projekt beatfactory-497615 den Zustimmungsbildschirm auf "In Produktion" stellen und einmal neu anmelden. NOCH NICHT AUTOMATISCH- ReelForge laedt weiterhin nichts von selbst hoch. Bewusst- der Kanal ist neu und im Warmup, und TikTok bleibt Hauptplattform.
Langform: eigenes Format, Querformat als WERT, Untertitel als Datei
Gebaut 2026-08-06, die ganze Kette vom Drehbuch zum Video (langschnitt, langstimme, languntertitel, langwolke, langmach; Format "voxlang", gesperrt bis zur Abnahme eines echten Videos). DREI ENTSCHEIDUNGEN, die man auch anders haette treffen können- (1) QUERFORMAT IST EIN WERT, KEIN SCHALTER. bau.py bekommt die Leinwand durchgereicht, Vorgabe bleibt Hochformat. Ein globaler Schalter waere kuerzer gewesen und genau deshalb falsch- hier arbeiten mehrere Sessions im selben Ordner, und ein Reel, das still im Querformat rauskommt, faellt erst am fertigen Video auf. (2) EIGENES FORMAT statt Schalter an vox- Leinwand, Takt und Textebene sind in allen drei Punkten gegenteilig; als Schalter bekaeme jeder Regler zwei Bedeutungen. (3) KEIN EINGEBRANNTER TEXT (Merts Entscheidung). Eingebrannte Untertitel sind eine Hochformat-Konvention — im Feed wird stumm gescrollt. Auf YouTube wird mit Ton geschaut, und Reel-Text lässt ein Langvideo nach Reel aussehen. Stattdessen eine SRT-Datei aus demselben Renderlauf, in dem die Wortzeiten ohnehin vorliegen. DIE STIMME KOMMT IN STUECKEN- 28.938 Zeichen passen in keine einzige Anfrage. Wer einfach zerschneidet, hoert an jeder Naht einen Neuanfang; deshalb geht zu jedem Stück der Text davor und danach als Zusammenhang mit (previous_text/next_text). Zusammengefuegt wird in der Cloud, weil auf dem Pi nicht gerendert wird. TAKT- 4,5s je Einstellung statt 2,8 beim Reel, und zwei begruendete Schnitte müssen 2,5s auseinanderliegen statt 1,3. Gemessen am Midgley-Drehbuch- 504 Einstellungen, Mittel 3,7s, keine unter 1,7 oder über 5,4. Mit den Reel-Werten waere jedes Bild in acht bis zehn Schnipsel zerfallen.
Ein Langvideo ist nicht ein langes Reel — die Zeitgrenze haette es zerrissen
Gemessen 2026-08-06 an acht echten Laeufen- ein 45-Sekunden-Reel braucht 3 bis 4,5 Minuten, davon rund 1,5 Minuten Anlauf. Also zwei Minuten echte Rechenzeit. Ein 31-Minuten-Video ist das Einundvierzigfache, hochgerechnet gut 80 Minuten — die Zeitgrenze des Cloud-Jobs stand auf EINER Stunde. Der Lauf waere nach 60 Minuten abgebrochen worden, ohne Ergebnis, nach einer Stunde Warten. Grenze auf VIER STUNDEN gesetzt (gcloud run jobs update reelforge-render --task-timeout=4h). Eine Obergrenze kostet nichts, solange sie nicht gebraucht wird; für die Reels ändert sich nichts. NOCH KEINE MESSUNG, sondern eine Hochrechnung — der erste echte Lauf ist auch die erste Messung.
Flow braucht einen laufenden PC — die fehlenden Bilder kamen über OpenArt
Merts Frage 2026-08-03, während er einige Tage weg war- "wir haben ja jetzt ein fertiges Flow-Skript, waere es jetzt nicht möglich eine Browser-Automation laufen zu lassen?" NEIN. flow_bot hängt sich an ein Chrome, in dem Mert SELBST angemeldet ist — das ist keine Bequemlichkeit, sondern die einzige Bauart, die Google zulaesst. Es braucht also einen eingeschalteten Rechner mit dieser Anmeldung; sein PC war aus (Syncthing meldete das Geraet offline). Auf dem Pi nachbauen scheidet aus- kein Google-Konto, und seine Zugangsdaten gehören nicht dorthin. DER WEG, DER OHNE PC GEHT- langbestellen.py über OpenArt. Entscheidend ist, dass es DASSELBE Bildmodell ist (nano-banana-pro), derselbe Auftragstext, dasselbe Format — die 22 Nachzuegler sehen aus wie die 91 aus Flow (alle 2752x1536). Unterschied ist allein der Preis- bei Flow 0, bei OpenArt 40 Credits je Bild. 22 Bilder = 880 Credits, von Mert freigegeben. Damit ist das Midgley-Bildmaterial vollstaendig.
Sprechertext darf nie zugeben, dass er ein Text ist — mechanisch geprüftneu
Mert am 2026-08-02 zum Langform-Skript: "Die Frage, um die es in den nächsten fünfundzwanzig Minuten geht" — "man sagt sowas nicht. Schau dir mal Skripte von Dokus an." Zutreffend, und der Fehler saß an acht Stellen. Es sind zwei Sorten. ERSTENS redet der Text über das Video (Laufzeit, "Halbzeit", "in diesem Kapitel", "wie eingangs erwähnt"). Solange der Text nur von Midgley redet, sitzt der Zuschauer 1924 in der Fabrik; fällt "in den nächsten 25 Minuten", sitzt er wieder auf dem Sofa vor einem Video — derselbe Effekt wie eine Kamera im Spiegel. ZWEITENS benotet der Erzähler sein eigenes Material ("das ist wichtig", "der Grund, warum diese Geschichte hängenbleibt"). Wer das schreibt, hat es nicht wichtig gemacht, sondern bittet den Zuschauer darum, es wichtig zu finden — Wirkung genau umgekehrt. Reparatur ist fast immer: Satz streichen, das Material stand ohnehin direkt dahinter. Neu: formate/vox/sprechtext.py prüft beide Sorten als FEHLER (blockiert den Bau) und dazu die Maße fürs Ohr als WARNUNG — Satzlänge (25/35), gestapelte Nebensätze, Passivanteil, unhörbare Zahlen. Nicht über Kommas gezählt: Aufzählungen sind gutes Handwerk. Einzige erlaubte Selbstnennung bleibt die gesprochene Kapitelkarte, weil sie Überschrift ist und kein Verweis.
Long-Form wird in KAPITELN gebaut — jedes mit eigener Karte, im Bild und gesprochen2026-08-02
Merts Entscheidung am 2026-08-02, zum Start der Long-Form-Videos (Querformat, 20-30 Minuten): "ich faende es geil wenn wir jedes Video so aufbauen dass es verschiedene Kapitel gibt. Und die Kapitel bekommen ein eigenes Bild mit Text im Bild — Kapitel 1. Thema xyz — und der Sprecher sagt das auch." DAS PASST GENAU ZU DEM, WAS DIE RECHERCHE SAGT. Ein 25-Minuten-Video ist nicht EINE lange Ursachenkette, sondern sechs bis zehn kurze. Der haeufigste Grund für einen Steilabfall in der Retentionskurve ist nicht schlechter Inhalt, sondern GLEICHFOERMIGKEIT — und eine Kapitelkarte ist ein Musterbruch, also genau das Gegenmittel. Nebenbei liefert sie die Zeitmarken für die YouTube-Beschreibung. DIE REGEL FÜR DIE KARTE, aus dem Schlussbild der Reels gelernt: der Text steht IM Bild, nicht als Stempel darüber, und er muss KURZ sein. Ein Wort ("RADIUM") kommt zuverlaessig, ein ganzer Satz kann als Buchstabensalat zurueckkommen. "KAPITEL 1 — DAS KLOPFEN" ist die Größenordnung; länger als rund 24 Zeichen wird der Titel nicht. Zweimal hat das beim Schlussbild buchstabengenau geklappt, das ist die Erfahrungsgrundlage. VOR DEM ERSTEN KAPITEL STEHT IMMER EIN INTRO (Merts Zusatz, gleicher Tag)- "um die Neugier und Spannung aufzubauen und eine offene, nicht beantwortete Frage im Raum stehen zu lassen." Deckt sich mit der Recherche: der Haken eines Langvideos hat rund 20 Sekunden und muss DREI Dinge tun — den Klick rechtfertigen, den Einsatz nennen und die erste Neugier-Schleife oeffnen, OHNE sie zu schließen. Das Intro ist damit kein Vorspann, sondern das Versprechen, das die restlichen 25 Minuten einloesen. Und die Frage, die es offenlaesst, ist die Klammer über alle Kapitel. WAS DAMIT AUCH ENTSCHIEDEN IST- der Schnittvertrag "eine Zeile = eine Szene = eine Datei" gilt für Long-Form NICHT. 25 Minuten waeren rund 300 Dateien; Long-Form läuft mit B-Roll, die 10 bis 20 Sekunden unter der Erzaehlung liegt. Die Kapitelkarte ist dabei die einzige Szene, die weiter fest an EINER Zeile hängt.
UEBERHOLT am 2026-08-08 — Google Flow hat ein Tageslimit, damit ist es für Long-Form raus2026-08-02
ACHTUNG, DIESER EINTRAG GILT NICHT MEHR. Mert am 2026-08-08- "ich habe ein Abo auf Google Flow, damit kann ich viel mehr Bilder am Tag generieren." WARUM DER ALTE BEFUND TROTZDEM RICHTIG GEMESSEN WAR- ohne Abo gibt Google Flow 50 Credits am TAG. Das deckt sich genau mit dem, was hier beobachtet wurde ("nach zehn Bildern plus Testlaeufen macht Flow dicht"). Gemessen wurde also der kostenlose Stand, nicht das Werkzeug. Mit Abo läuft die Zuteilung nicht mehr täglich, sondern MONATLICH- AI Plus 200, AI Pro 1.000, AI Ultra 10.000 bzw. 25.000 Credits im Monat. Nicht verbrauchte Credits verfallen, sie wandern nicht in den nächsten Monat. DER BEWEIS LAG DIE GANZE ZEIT IM ORDNER, und zwar vom SELBEN ABEND. Die 113 Bilder in uploads/lang_midgley/bilder stammen aus Flow, geholt und benannt von flow_bot.py- 83 Stück am 2026-08-02 zwischen 21:27 und 23:08, weitere 22 am 2026-08-03 in fünf Minuten, 8 Nachbesserungen am 2026-08-07. Der Eintrag hier entstand also am Nachmittag desselben Tages, an dessen Abend der Bot das Gegenteil bewiesen hat — korrigiert wurde er nie. DAMIT IST BEIDES ERLEDIGT- das Kontingent und der Beweisdurchlauf. flow_bot.py läuft, holt und benennt. KORREKTUR AM 2026-08-10 (von Mert): Hier stand "1.000 Credits im Monat". Falsch war nicht nur die Zahl, sondern das Modell- BILDER kosten in Flow gar keine Credits, sie sind nur nach Stueckzahl je Tag gedeckelt. Credits (200 im Monat plus 50 am Tag) gehen ausschliesslich für VIDEO drauf, 7 je 4-Sekunden-Clip. Die Bildkosten eines Reels sind damit NULL. Naeheres in der Aufgabe "Flow-Credits im Auge behalten". DIE LEHRE, DIE BLEIBT- zwei Stück. Erstens- ein beobachtetes Limit ist nicht dasselbe wie das Limit des Werkzeugs; hier wurde aus einer Beobachtung am Gratis-Zugang eine Grundsatzentscheidung ("für Long-Form raus"). Zweitens, und das ist die teurere- ein Eintrag, der eine Sackgasse festhaelt, muss zurück auf den Tisch, sobald jemand die Sackgasse durchfaehrt. Sonst planen sechs Tage später alle um ein Hindernis herum, das es nicht mehr gibt. DER URSPRUENGLICHE EINTRAG, zur Nachvollziehbarkeit- Gefunden am 2026-08-02, nachdem der halbe Abend in einen Browser-Roboter für Flow geflossen war (flow_bot.py). Nach den zehn Bildern eines Reels plus einigen Testlaeufen macht Flow dicht bis zum nächsten Tag. WARUM DAS DIE ENTSCHEIDENDE ZAHL IST- die ganze Diskussion drehte sich um Geschwindigkeit (Agent 30 Minuten, Skript 10, OpenArt 2). Ein Tageslimit ist aber eine haertere Grenze als Tempo: für ein Reel mit 10 Bildern reicht ein Tag bequem, für ein Long-Form-Video mit rund 150 Bildern reicht er nicht — egal wie schnell das Skript ist. WAS BLEIBT- flow_bot.py ist fertig gebaut und die Anker sind gelernt; es fehlt nur der Beweisdurchlauf. Für Reels ist der Weg brauchbar und kostet keine Credits. Für Long-Form fuehrt kein Weg an einer Schnittstelle vorbei — entweder OpenArt (6.000 Credits je Video, also zwei im Monat) oder direkt bei Google (3 bis 9 Dollar je Video, parallel, kein Browser). Siehe tasks. WAS DER ABEND SONST GEBRACHT HAT, unabhängig von Flow- die Bestellung läuft jetzt vierfach parallel, es gibt eine Abnahme die laut scheitert, und auftrag.json mit festen Zielnamen. Das gilt für jeden Bildweg.
Jedes Reel endet mit einer Frage — und sie steht IM Bild, nicht als Stempel2026-08-01
Merts Wunsch am 2026-08-01- "ganz am Ende des Videos sollte so eine Frage kommen, das regt nochmal die Spannung auf und lässt den Zuschauer eine Frage zum Denken. Es muss keine Frage direkt an den Zuschauer sein, kann so eine generelle Frage sein." Und praeziser nachgeschoben- "Sprecher plus grosse Frage, vllt die Frage nicht als Caption sondern im KI-Bild drinne, und das Bild zeigt Motive die das gesamte Video nochmal zusammenfassen, wie eine Sammlung der Motive aus dem Video." WAS GEBAUT WURDE- die letzte Szene ist jetzt ein eigener Typ ("schluss: true"). Ihr Bildauftrag sammelt die Hauptmotive der uebrigen Szenen zu einer Collage (hoechstens fünf — mehr wird ein Wimmelbild, und die Schrift geht darin unter) und verlangt die Frage als grosse, lesbare Schrift im Bild. Im Schnitt wird die Szene NICHT geteilt und faehrt ruhig (die Frage will gelesen werden), und sie bekommt KEINEN Textstempel — zweimal dieselbe Frage liest sich als Fehler. DAS RISIKO, ausdruecklich- das ist die unzuverlaessigste Stelle der ganzen Kette. Ein Etikett aus einem Wort ("RADIUM") kommt sauber; ein ganzer Fragesatz kann als Buchstabensalat zurueckkommen, und dann ist das Letzte, was vom Reel haengen bleibt, ein Fehler. Drei Gegenmassnahmen- die Frage darf hoechstens 58 Zeichen haben, sie wird im Auftrag dreimal genannt und als einziger Text im Bild verlangt, und sie MUSS von Hand angesehen werden. Automatisch prüfen lässt sich das nicht. WAS DER BAU ABLEHNT, bevor Credits fliessen- Frage ohne Fragezeichen, Frage länger als 58 Zeichen, Frage die vom gesprochenen Satz abweicht, mehr als ein Schlussbild, Schlussbild das nicht die letzte Szene ist, Schlussbild mit bewegt: true. NOCH NICHT AM ECHTEN BILD GEPRÜFT — kostet 40 Credits. Siehe tasks.
Sinnhaftigkeit wird jetzt geprüft — Bild ans WORT gebunden, nicht an die Position2026-08-01
Merts wichtigster Befund (2026-08-01)- "Es gibt immer noch Stellen die nicht so viel Sinn machen. Bei "kein Zeuge" wird auf den Hubschrauber gezoomt." Dazu die Bitte dahinter- "schau dass so eine Sinnhaftigkeit im ganzen Video gecheckt wird und auch für alle zukuenftigen Videos". ZWEI VERSCHIEDENE FEHLER, die er zusammen genannt hat. (A) BILD SITZT AUF DEM FALSCHEN WORT. Der Hubschrauber IST die Fahndung, nicht "kein Zeuge" — und der Fehler war strukturell, kein Vertipper. Die Einstellungsfolge war rein POSITIONSGEBUNDEN (Eintrag 1 für die erste Einstellung, 2 für die zweite). Wie viele Einstellungen eine Zeile bekommt, hängt aber von ihrer Laenge ab (Fuellschnitte) und lässt sich beim Schreiben nicht sicher vorhersagen. Wer sich verzaehlt, verschiebt die GANZE Folge — und das Video sieht trotzdem normal aus. Genau die Fehlerklasse, gegen die das Projekt sonst ueberall absichert. BEHOBEN- ein Eintrag darf an ein Wort gebunden werden ("ol@Fahndung"). Das Bild sitzt dann auf dem Wort, so wie der Schnitt auch, und die Anzahl der Einstellungen ist egal. Fehlt das Ankerwort in der Zeile, bricht der Bau ab statt still zurueckzufallen. Nachgezaehlt- von 10 Bildszenen des Phantom-Reels waren SECHS geraten, nicht nur die eine, die Mert gesehen hat. (B) DAS BILD TRAEGT DIE INFORMATION NICHT. Merts Beispiel- bei "Biografie: Osteuropaeerin, wohnungslos, seit Jahren auf der Flucht" zeigt das Bild drei LEERE Karteikarten; er haette gern die drei Merkmale darauf. Die Ursache stand in UNSEREM Auftrag, nicht im Modell- er verlangte woertlich "a SINGLE small typewriter caption strip" und "no other labels". Das Modell lieferte also genau das Bestellte. BEHOBEN- "etikett" nimmt jetzt bis zu DREI Beschriftungen, jede einem Element zugeordnet. Hoechstens drei, weil Schrift die unzuverlaessigste Stelle jedes Bildmodells ist. WIRKT ERST AUF NEUE BILDER und kostet je Szene 40 Credits — siehe tasks. DIE ANTWORT AUF "FÜR ALLE ZUKUENFTIGEN VIDEOS"- ein neuer Pruefbogen, "ausschnitt --sinn". Er legt jeden Satz neben genau den Bildausschnitt, der dabei läuft, für das ganze Reel auf EINEM Bogen, und meldet zusätzlich, was sich mechanisch prüfen lässt (Zeile ohne Angabe, geratene Zuordnung, Anker dessen Wort fehlt). Automatisch ENTSCHEIDEN, ob Bild und Satz zusammenpassen, kann kein Programm zuverlaessig — die Entscheidung SICHTBAR machen kann es. Der Bogen ist Pflicht vor jedem Reel und steht so im Skill. DABEI EIN FEHLER IM PRUEFWERKZEUG SELBST GEFUNDEN- die erste Fassung zeigte eine Spalte je SATZ und uebersah damit alle Einstellungen von Zeilen mit nur einem Satz, also genau die Haelfte der Faelle. Ein Pruefbogen, der die Haelfte nicht zeigt, ist schlimmer als keiner — man haelt ihn für vollstaendig.
Dritte Runde: keine schraegen Fahrten, laengere Mindestschnitte, freie Zielpunkte2026-08-01
Merts Urteil zur zweiten Fassung (2026-08-01)- "besser, aber 2 Sachen" — daraus wurden drei Änderungen. (1) "ES SOLLEN KEINE QUER-KAMERAFAHRTEN GEBEN. Nur horizontal, vertikal und Zoom in oder Zoom out." Die Schwenks waren immer schon sauber auf einer Achse — schraeg wurde es bei den NAHEN Einstellungen, und zwar unbeabsichtigt- der Ausschnitt wurde je Bild neu ins Bild hineingeklemmt. Liegt das Ziel nah am Rand, greift diese Klemme, und weil das Fenster beim Zoomen seine Größe ändert, ändert sich auch der geklemmte Wert. Der Mittelpunkt wanderte dadurch während des Zooms — in x und y verschieden stark, also schraeg. JETZT wird EINMAL geklemmt, für das größte Fenster der Fahrt; was dort hineinpasst, passt bei jedem groesseren Zoom erst recht. Der Mittelpunkt steht fest, übrig bleibt ein reiner Zoom. (2) "DIE SCHNITTLAENGE DER KUERZESTEN CLIPS IST ETWAS ZU KURZ." Jetzt ZWEI Schwellen statt einer, weil nicht jeder Schnitt gleich viel wert ist- Fuellschnitte (die nur den Takt halten) mindestens 1,50 s, begruendete Schnitte an Satzgrenzen mindestens 1,30 s. Grund für die Ausnahme- bei einer Aufzaehlung wie "Ein erwuergter Rentner. Ein Einbruch. Ein Motorrad." dauert der mittlere Satz nun einmal nur gut eine Sekunde; ihn auf Fuell-Laenge zu zwingen hiesse, genau den Schnitt wegzulassen, den Mert an dieser Szene gut fand. OFFEN- die kuerzeste Einstellung dort bleibt damit bei rund 1,4 s. Ist ihm das immer noch zu kurz, kostet es den dritten Schnitt — das ist seine Entscheidung, nicht meine. (3) "DER ZOOM IN BEIM GEKLAUTEN MOTORRAD IST ZU WEIT OBEN." Stimmte, und das Sechser-Raster konnte es nicht loesen- die oberen Rasterpunkte schnitten das Motorrad unten ab, die mittleren erwischten das Etikett "TATORTE" am Rand. Beim Sessel dasselbe in der anderen Richtung. Deshalb gibt es jetzt FREIE Zielpunkte im Drehbuch- "x80y38" ist ein Punkt in Prozent, "x80y38z205" zusätzlich mit eigenem Zoom. Das Raster bleibt als Abkuerzung für den Normalfall. Szene 4 läuft jetzt auf x18y36z205 / mm / x80y38z205 — alle drei Motive vollstaendig, kein Etikett angeschnitten. DAZU das Pruefwerkzeug nachgezogen- "ausschnitt --weit-nah" zeigt jetzt die GANZE Folge statt nur der ersten nahen Einstellung. Vorher haette es genau den Fehler nicht gezeigt, um den es hier ging.
Nachgebessert: geschnitten wird nach BEGRUENDUNG, und die Kamera faehrt ueberall gleich schnell2026-08-01
Merts Urteil zum ersten Reel mit dem neuen Schnitt (2026-08-01, drei getrennte Befunde — alle drei zutreffend, alle drei behoben). (1) "DIE KAMERAFUEHRUNGEN SOLLTEN IMMER DIE SELBE GESCHWINDIGKEIT SEIN." Der Fehler war grundsätzlich- je Fahrt stand ein FESTER Zoomwert (Schwenk 1,18), verteilt über die Dauer der Einstellung. Seit die Einstellungen unterschiedlich lang sind (1,2 bis 2,8 s), heißt derselbe Weg in kuerzerer Zeit schlicht- schneller; die kuerzeste Einstellung fuhr mehr als doppelt so schnell wie die laengste. Bei 4,8 s je Bild fiel das nicht auf, mit dem neuen Takt sofort. JETZT ist die Geschwindigkeit die feste Größe (bau.TEMPO = 6 % des Bildes je Sekunde) und der Weg ergibt sich aus der Dauer. Nachgerechnet- 1,2 s / 2,0 s / 2,8 s fahren alle mit exakt 6,00 % je Sekunde. DAZU RUECKGAENGIG- die weiche Beschleunigungskurve vom 2026-07-31 (smoothstep). Die war richtig, SOLANGE eine Einstellung 4,8 s stand: dann gibt es eine lange Mitte mit gleichmaessigem Lauf, und das Anfahren wirkt wie eine echte Kamera mit Masse. Bei 2 Sekunden besteht die Einstellung nur noch aus Anfahren und Bremsen — die Geschwindigkeit ist NIE konstant. Jetzt linear. Den harten Einsatz verdeckt der Schnitt, dafür ist er da. (2) "MANCHE KAMERAFUEHRUNG IST ZU ABGEHACKT, ALSO ZU WENIG FPS." Es lag NICHT an der Bildrate, die war immer 30. Es lag an zoompan- der Filter schneidet sein Fenster auf GANZE Pixel und lieferte direkt in 1080x1920. Eine langsame Fahrt verschiebt sich damit um weniger als einen Pixel je Bild — heraus kommt kein Gleiten, sondern Stehen mit gelegentlichem Ein-Pixel-Sprung, und je LANGSAMER die Fahrt, desto schlimmer. Jetzt rechnet zoompan in doppelter Größe und wird danach heruntergerechnet (bau.PUFFER); aus dem ganzen Sprung wird ein halber, den die Verkleinerung in Zwischentoene aufloest. (3) "DIE AUSWAHL MACHT NICHT OFT SINN ... man merkt es stark bei der Szene: ein erwuergter Rentner, ein Einbruch, ein Motorrad. In dieser Szene sind diese 3 Dinge die genannt werden aufgefuehrt, die Schnitte aber sind komplett Wirrwarr." Der schwerste der drei Befunde, und der Fehler war konzeptionell- die erste Fassung schnitt nach DAUER (alle 2,8 s) und nahm dafür irgendeine Wortgrenze. Ein Schnitt ohne Grund liest sich als Zufall, egal wie gut der Takt stimmt. ZWEI ÄNDERUNGEN. Erstens WO- gesucht wird jetzt nach Begruendung, in dieser Reihenfolge- Satzgrenzen innerhalb der Zeile (steht schon in der Zeichensetzung und kostet nichts), dann das markierte Wort, und erst danach ein Fuellschnitt als Notnagel. "Ein erwuergter Rentner. Ein Einbruch. Ein Motorrad." sind damit automatisch drei Einstellungen. Zweitens WAS- "nah" im Drehbuch ist jetzt eine FOLGE (nah: [ml, mm, or]) statt eines einzelnen Zielpunkts, mit "weit" als gueltigem Eintrag für die Totale. Die Folge wird der Reihe nach abgearbeitet, das Bild folgt also dem Satz. Ein Schnitt an der richtigen Stelle nuetzt nichts, wenn danach das Falsche im Bild ist. GEPRÜFT- 11 Probengruppen (reine Rechnung, kein ffmpeg), darunter Merts Szene- drei Sätze ergeben drei Einstellungen, die Schnitte sitzen auf den Satzanfaengen, und die Ziele stehen in der Reihenfolge Sessel → Fenster → Motorrad.
Vox schneidet INNERHALB der Zeile — der Takt war das Problem, nicht das Bild2026-08-01
Gebaut 2026-08-01. GEMESSEN STATT GEAHNT- am Phantom-Reel stehen 12 Szenen auf 58,6 s, ein Bild also im Schnitt 4,8 Sekunden, die laengste Szene 7,6. Reels dieser Machart schneiden alle 1,5-2,5 s. Dazu Kamerafahrten von 13-17 % über diese ganze Zeit, rund 3 % je Sekunde — unter etwa 5 % je Sekunde liest das Auge eine Fahrt gar nicht als Bewegung. Das ist Merts "zu wenig Bewegung, zu wenig Input fuers Gehirn", und es ist NICHT die Bildqualitaet. WAS JETZT PASSIERT- eine Szene zerfaellt in mehrere EINSTELLUNGEN desselben Bildes- Totale, naeher heran, Totale, geschnitten auf dem *markierten* Wort (dessen Zeit liegt ohnehin auf ~90 ms genau vor und lag ungenutzt herum). Phantom- 25 Einstellungen statt 12, im Mittel 2,3 s. Kostet NICHTS- es kommt kein Material dazu, nur ein anderer Ausschnitt. Neu- formate/vox/einstellung.py (Planung) und formate/vox/ausschnitt.py (ansehen/ausrichten, Pillow, läuft auf dem Pi). DER VERTRAG BLEIBT- eine Skriptzeile ist weiter EINE Szene und EINE Datei. Die offene Aufgabe "Mehr als ein Bild je Skriptzeile" ist damit anders geloest als gedacht- ohne den Vertrag aufzuweichen und ohne Credits. WARUM KEIN ZWEITES BILD BESTELLT WIRD- war mein erster Plan (+200 Credits je Reel). Mert hat den Testauftrag in Google Flow durchlaufen lassen und ihn zerlegt- "es sieht aus wie das Original, das ist im Endeffekt einfach nur ein Ausschnitt vom Original Bild, dafür braucht man keine extra KI-Bildgenerierung". Er hat recht, und mein Test war schlecht gebaut- ich hatte "dieselbe Collage, nur naeher" bestellt, und das IST per Definition ein Ausschnitt. WIE WEIT MAN HINEINGEHT- 1,85. Rechnerisch waere bei 1,42 Schluss (Bilder sind 1536 px breit, Video 1080), aber am echten Bild nachgesehen ist das zu vorsichtig- ein Halbton-Bild besteht aus Druckpunkten, groessere Punkte liest man als groeberes RASTER, nicht als Unschaerfe. Erst ab etwa 2,4 verlieren die Teile ohne Raster ihre Kante. Vergleichsstreifen- uploads/vox_phantom_takt/vorschau/. WOHIN GEZIELT WIRD- neues Feld "nah" im Drehbuch (ol/om/or/ml/mm/mr), das holen.py in den DATEINAMEN zieht — derselbe Grund wie beim Einstiegspunkt der Archiv-Clips- was neben der Datei liegt, kann sich von ihr loesen. EINE FALLE, DIE SOFORT ZUGESCHLAGEN HAT- die nahe Einstellung kann ein Etikett mitten durchschneiden ("KEINE AUSSAG"). Das liest sich als Fehler, nicht als Bildausschnitt. Deshalb wird der Zielpunkt je Szene von Hand gesetzt und mit ausschnitt --weit-nah abgenommen, statt sich auf die Mitte zu verlassen. WAS NICHT GETEILT WIRD- Videoclips. Sie bauen über ihre Laufzeit die Collage auf; ein Schnitt hinein zerschlaegt genau das, wofür bezahlt wurde. Eine lange bewegte Szene bleibt damit die einzige Stelle über 3 Sekunden. AUSGEROLLT UND GESCHNITTEN am selben Abend (render:v35, auf Merts Ansage "mach du das" — sonst waere das Ausrollen Sache der Reelforge-Sitzung). Guenstiger Fall- seit dem vorigen Abbild v34 lag ausser dieser Vox-Arbeit nichts Neues vor, es ging also keine fremde Baustelle mit live. Die Pflichtpruefungen liefen sauber durch, der Held-Stil bei 1,2 % Abweichung (Grenze 2 %). ECHTE ZAHL AUS DEM RENDERPROTOKOLL- "28 Einstellungen, im Mittel 2.1s, laengste 6.3s" (meine Schätzung vorher war 25 / 2,3 s). Die laengste ist Szene 10, ein Videoclip — die werden bewusst nie geteilt. WAS NOCH NICHT BEURTEILT IST- ob es im BEWEGTEN Bild traegt. Belegt ist bisher nur, dass der Plan angewandt wurde (Protokoll) und dass die Datei sauber ist (1080x1920, 30 B/s, 58,6 s). Ob der Takt gut aussieht, sagt Mert. Siehe tasks.
Der Textstempel sitzt eine Zeile höher — ein Wert für alle drei Plattformen2026-08-01
Entschieden 2026-08-01 nach Merts Befund am fertigen Reel- "die Captions sind zu niedrig für YouTube, es müsste genau um eine Zeile hoch. Bei 2 Zeilen Caption muss Zeile 2 auf Hoehe von Zeile 1." Der Abstand nach unten geht von 300 auf 402. 102 IST GEMESSEN, NICHT GEGRIFFEN- es ist die Zeilenhoehe der Stempelschrift bei Größe 84 (Bricolage Grotesque Bold, Oberlaenge 79 + Unterlaenge 23). Der Stempel ist unten ausgerichtet und wächst nach oben — eine Zeilenhoehe mehr Abstand verschiebt den ganzen Block um genau eine Zeile, gleich ob er ein- oder zweizeilig ist. KEINE VARIANTEN JE PLATTFORM, ausdrueckliche Ansage von Mert ("bau jetzt nicht 3 verschiedene Varianten für die 3 Social-Media-Plattformen"). Also gilt die strengste Vorgabe für alle- YouTube Shorts blendet unten mehr ein als TikTok (Titel, Kanalzeile, Beschreibung), und unsere Zahl stammte von den engeren Plattformen. Das kostet auf TikTok etwas Bildflaeche und ist der Preis dafür, nur EINE Datei hochzuladen statt drei. NEBENBEI- das ist der UNTERE Rand. Der offene Punkt zum RECHTEN Rand ist eine andere Sache und von Mert abgeraeumt (Karte weiter unten).
Der rechte sichere Rand bleibt — Merts Entscheidung, gegen meinen Einwand
Am 2026-08-01 vorgelegt und von Mert abgeraeumt: "das passt schon". Die Aufgabe ist damit aus der Liste raus. HIER STEHT SIE, damit die nächste Session die Messung nicht noch einmal erhebt und die Frage nicht noch einmal stellt. WAS GEMESSEN WAR (2026-07-31): Der sichere Bereich in caption_engine.py stammt aus INSTAGRAMS Flaechenangaben, Hauptplattform ist aber TikTok. Oben, unten und links ist Instagram strenger, also gedeckt. Nur rechts nicht: TikTok braucht 120-140 px für seine Knopfleiste, gesperrt sind 90. Die breitesten Textzeilen ragen damit rechnerisch 30-50 px unter die Knoepfe. MEIN EINWAND, unveraendert: am gerenderten Video sieht man das NIE, weil dort keine Knoepfe sind — es faellt erst am Handy auf, und dann an jedem bereits hochgeladenen Reel gleichzeitig. WAS DAGEGEN SPRICHT, ihn trotzdem anzufassen: es ist eine Rechnung, keine Messung am echten Geraet, und caption_engine.py benutzen ALLE Formate — eine Änderung dort verschiebt auch Lyrics, Story und Spotify. WIEDER AUFMACHEN, WENN: an einem echten TikTok-Upload sichtbar Text unter der Knopfleiste steht. Dann SICHER_X rechts von 0.917 auf rund 0.885 — und zwar aus der Session "Reelforge", nicht aus einer Format-Session.
ÜBERHOLT — Kritzelebene und wortweiser Text sind verworfen
Am 2026-08-01 gebaut, am selben Tag an einem echten Reel geprüft und von Mert verworfen. Die Karte darunter beschreibt, was gebaut wurde; sie gilt technisch weiter, aber die Sache ist AUS (beide Vorgaben stehen auf False). DER TESTFILM- uploads/vox_phantom_kritzel/REEL.mp4, dasselbe Reel wie uploads/vox_phantom/ mit denselben Bildern und derselben Stimme, nur mit den zwei Neuerungen. Merts Urteil- "komplett tot, die Zeichnung muss wenn schon in der Videogenerierung mit dabei sein, so als würde man wirklich auf das Blatt schreiben". Auf Nachfrage- der wortweise Textstempel hat AUCH nichts gebracht. WARUM ES NICHT GING- Meine erste Erklärung war, dass die Kritzelei am Bildschirm klebt, während die Kamera über das Papier faehrt (vier von sechs sassen auf einem wandernden Bild). Merts Widerspruch- "es lag nicht nur an der Kamerafahrt, man merkt einfach dass es nach dem Video hinzugefuegt wurde". Er hat es gesehen, ich nicht — sein Befund gilt. Der Kern ist damit- eine zweite Ebene bleibt eine zweite Ebene. Ein Strich, der nicht im selben Arbeitsgang wie das Bild entsteht, hat nicht dessen Papierfaser, Druckraster, Licht und Schatten. DER WEG, DER BLIEBE, falls es je wieder aufkommt- NICHT das Videomodell (es kennt die Sprecherspur nicht, lässt sich nicht steuern, und jede Szene mit Strich müsste ein Clip statt eines Standbilds sein). Sondern das BILDmodell- nano-banana-pro kann image2image und kostet dabei genauso viel wie ein neues Bild (40 Credits, am 2026-08-01 direkt bei OpenArt abgefragt). Szenenbild normal erzeugen, dann dasselbe Bild mit "male einen roten Kringel um X, direkt aufs Papier, aendere sonst nichts" zurueckschicken, und im Schnitt auf dem gesprochenen Wort von A auf B umschalten. Rund +200 Credits je Reel (+30 %). Mert hat das gehört und entschieden- "wir lassen es erstmal sein". WAS BLEIBT- die eigentliche Ursache für "zu wenig Bewegung" ist wahrscheinlich, dass EINE SKRIPTZEILE EIN BILD bedeutet. Ein Sechs-Sekunden-Beat ist sechs Sekunden derselbe Bildausschnitt. Das behebt kein Strich. Siehe tasks.
Vox bekommt eine Kritzelebene — und der Text läuft Wort für Wort
ÜBERHOLT durch die Karte darüber — gebaut wurde es so, benutzt wird es nicht. Entschieden 2026-08-01 nach Merts Befund: "unsere vox videos stossen noch nicht genug dopamin aus, es hat zu wenig bewegung, zu wenig input für das gehirn". Er hat recht — ein Beat war sechs Sekunden Standbild mit langsamer Fahrt und einem Textblock, der einmal aufblendet. ZWEI ANTWORTEN, beide kostenlos, weil gezeichnet statt bestellt. (1) WORTWEISER STEMPEL: jedes Wort erscheint auf seinem gesprochenen Wort. Die Wortzeiten lagen seit jeher auf ~90 ms genau vor und wurden nie benutzt. Der Satz steht dabei von Anfang an vollstaendig da und wird nur DURCHSICHTIG geschaltet — sonst ändert sich mit jedem Wort der Zeilenumbruch und der Block zappelt. Regler "wortweise". (2) KRITZELEBENE (formate/vox/kritzel.py + kritzel.json): Pfeile, Kringel, Haken, Kreuze, Klammern, im Skript gesteuert ([kringel@Fehlalarm]) und auf das gesprochene Wort gesetzt. Sie zeichnen sich in 0,34 s auf, halten bis 2,8 s und kochen dabei (alle zwei Zeichenbilder wird der Strich neu ausgewuerfelt). Als PNG-Folge mit 15 B/s über das Bild gelegt — 15, weil nur Teiler von 30 taugen, sonst humpelt der Takt wie beim Stop-Motion-Wert vorher. Regler "kritzel". VERWORFEN: Edge Boil auf dem BILD selbst. Vom Bildmodell kommt ein flaches Pixelbild ohne Ebenen; ein Displacement-Filter lässt nicht die Schnittkante zittern, sondern Textur, Schatten und Staub gleichzeitig — Hitzeflimmern statt Handarbeit. Beim selbst gezeichneten Strich ist Kochen dagegen richtig. NOCH OFFEN: einzelne WOERTER einkringeln. Dafür müsste man wissen, wo libass das Wort hingemalt hat; das ginge nur, wenn der Stempel selbst mit Pillow gesetzt wird (Umbau des Textsystems). Bewusst verschoben, bis Mert die jetzige Stufe beurteilt hat.
Zonen und Masse der Kritzeleien stehen in kritzel.json, nicht im Code
Weil ZWEI Seiten sie lesen: kritzel.py malt das Video damit, ui.jsx zeichnet die Vorschau damit. Zwei Zahlenlisten würden auseinanderlaufen, und man saehe es erst am fertigen Reel — die Lehre aus dem Bewegungssystem der Strichfiguren, wo die Vorschau die Bewegung bis heute nicht zeigt. Nachgeprueft: beide Seiten rechnen für dieselbe Form/Zone identische Bildkoordinaten. WAS DIE VORSCHAU BEWUSST NICHT NACHBAUT: das Zittern und das Kochen. Das waere eine zweite Umsetzung derselben Sache. Die Vorschau beantwortet WO, WIE GROSS und WANN; wie der Strich aussieht, zeigt der Kontaktbogen (python3 -m formate.vox.kritzel --blatt), und der läuft mit Pillow auf dem Pi, faellt also nicht unter die Render-Sperre.
Die Zeichenroutinen sind aus strichfiguren KOPIERT, nicht importiert
Rund neunzig Zeilen (_wackeln, _anteil, _male, _rausch) stehen jetzt zweimal da. Absicht: Vox ist freigeschaltet und läuft bei Mert, Strichfiguren ist eine Baustelle mit einer EIGENEN Sitzung, die dort jederzeit umbenennen darf. Ein laufendes Format darf nicht von einer Baustelle abhaengen. DABEI EIN FEHLER GEFUNDEN, der in der Vorlage noch steckt: die Gesamtlaenge für den Aufbau wurde an den GLATTEN Strichen gemessen, verbraucht aber an den GEWACKELTEN — und die sind länger, weil sie schlaengeln. Das letzte Bauteil wird dadurch nie fertig gezeichnet, auch bei aufbau=1.0. Hier behoben (erst wackeln, dann messen); in formate/strichfiguren/figur.py steht er noch — gehört der Sitzung RF-Strichfiguren, siehe tasks.
Telegram erinnert alle zwei Tage ans Hochladen
Eingerichtet 2026-07-31 auf Merts Wunsch. Der Kanal lebt von Regelmaessigkeit, das Hochladen ist Handarbeit und geht im Alltag unter. WAS LÄUFT: /home/pi/scripts/aktenlage_reminder.py, geweckt von aktenlage-reminder.timer täglich um 18:30. Die Nachricht enthaelt die drei Sachen, die man beim Hochladen falsch machen kann (Datei aus ReelForge statt von TikTok, Beschreibung mit Haken, eigene Frage als Kommentar). WARUM TÄGLICH GEWECKT: systemd kann "jeden zweiten Tag" nicht sauber — "*-*-1/2" zählt Tage im MONAT und schickt am Monatswechsel zwei Tage hintereinander. Also weckt der Timer täglich und das Skript entscheidet anhand des letzten Versands. Schwelle 47 statt 48 Stunden, sonst rutscht jede zweite Erinnerung um einen ganzen Tag. ZUGANG: Bot und Chat-ID aus /home/pi/instapi/.env, kein zweites Geheimnis. NEBENBEFUND FÜR DEN HUB: weekly_report.py und monthly_cost_review.py lesen aus /home/pi/investpi/.env — die Datei gibt es nicht (mehr). Beide brechen still ab und laufen trotzdem weiter im Timer.
Der Kanal heißt Aktenlage — und traegt NUR die Erklaer-Reels
Entschieden von Mert am 2026-07-31, aus vier Vorschlaegen gewählt. NAME: "Aktenlage". Ein Wort, deutsch, nach einmal Hoeren richtig zu schreiben, als Wort selten genug, um auffindbar zu sein. Der Ermittler-Ton passt zum Papiercollage-Look, ohne ihn zu erklären. WARUM NICHT "VOX" IM NAMEN: VOX ist ein deutscher Fernsehsender (RTL-Gruppe), dazu gibt es Vox Media in den USA. "Vox-Stil" bleibt unser INTERNES Wort für die Optik — als Marke waere es im deutschsprachigen Markt eine Markenrechtssache und obendrein verwirrend. EIN KONTO = EIN THEMA. Auf diesen Kanal gehören nur die Erklaer-Reels (Petrow, Radium-Maedchen, Phantom von Heilbronn). NICHT die Lyric-Videos, Spotify-Kacheln oder die Archiv-Doku: der Algorithmus lernt bei jedem Video neu, wem er den Kanal zeigt — mischt man zwei Sorten, lernt er gar nichts und beide laufen schlechter als allein. Die Musik-Sachen haben bei instapi ohnehin eigene Accounts (Mila, Riley). BEKANNTES RISIKO DES NAMENS: Er klingt nach True Crime. Die bisherigen Geschichten sind breiter (Beinahe-Atomkrieg, Arbeitsmedizin, Ermittlungspanne). Gegenmittel: die Kanalbeschreibung weit halten und unter den ersten fünf Videos mindestens eines haben, das kein Verbrechen ist — die ersten Videos setzen die Erwartung, nicht der Name. NOCH OFFEN: ob der Handle @aktenlage auf TikTok, YouTube und Instagram frei ist. Von hier aus nicht seriös pruefbar (beide Plattformen liefern Maschinen nur eine leere Huelle aus) — steht als Aufgabe bei Mert.
Strichfiguren- Objekte. Die Pose zeigt die Haltung, erst das Objekt den Inhalt
Gebaut 2026-08-01 nach Merts Einwand- "was ist aber mit den ganzen zeichnungen oder emoji oder bilder um zu wissen worueber er spricht. das wurde doch bestimmt in den tutorials angegeben". Es stand tatsächlich drin und war uebersehen worden. WAS IN DER MASTERCLASS STEHT- jede Szene besteht aus Charakter PLUS Gegenstaenden. "Erstelle 20 Prompts, die exakt zum Skript passen"; Beispiele- "brennende Schwerter, Einraeder, Erdbeben, und natürlich der Charakter", "Fussspuren hinter ihr, die ein Wort bilden". Ein Bild je rund zehn Woerter Skript. WAS VORHER WAR- jede Szene NUR die Figur auf leerem Papier. Die Pose zeigt eine HALTUNG, nie den INHALT- man sah "jemand denkt nach", nie "jemand denkt an eine Erinnerung". Eine Figur allein auf weissem Grund ist ein Piktogramm, kein Erklaervideo. Genau das war der Rest von Merts "Kinderkacke". JETZT- objekte.json mit 19 Gegenstaenden (Karton, Aktenschrank, Buch, Stift, Bilderrahmen, Staffelei, Uhr, Bett, Tuer, Treppe, Berg, Handy, Blitz, Pfeil, Kreuz, Haken, Sprechblase, Waage, Menge), im Skript über [objekt:name] angefordert. Reine Daten wie posen.json- Linien, Kreise, Boegen in einem 0..1-Kasten. Ein neues Objekt ist ein Eintrag, keine Codeaenderung. ZWEI ENTSCHEIDUNGEN, DIE ERKLÄRUNG BRAUCHEN- (1) "menge" wird aus echten kleinen Strichfiguren gezeichnet statt aus einem Symbol. Eine Menge aus fremden Piktogrammen waere eine andere Bildwelt; dieselbe Figur in klein ist dieselbe Welt. Kostet nichts, weil der Zeichner ohnehin da ist. (2) DIE FIGUR WEICHT AUS. Sie ist rund 1000 px hoch in einem 1080 px breiten Bild — mittig bleibt für nichts daneben Platz. Steht ein Objekt am Boden, rutscht sie auf 30 % der Breite, wie ein Zeichner es taete. Der erste Objekt-Kontaktbogen zeigte genau diesen Fehler- fast jedes Objekt lief aus dem Bild, weil die Groessen an der Figurenhoehe hingen und die fast der Bildbreite entspricht. WAS DER GESPROCHENE TEXT DAZU SAGT- nichts. Objekte sind Anweisungen in eckigen Klammern, der Sprechertext bleibt Wort für Wort derselbe (per diff nachgewiesen). Ein bestehendes Reel lässt sich also bebildern, ohne die Stimme neu zu erzeugen. FEHLER, DEN NUR DIESER DIFF GEFUNDEN HAT- stimmentext() entfernte die neuen Anweisungen nicht, ElevenLabs haette "[objekt:bilderrahmen]" vorgelesen bekommen. Es gibt jetzt EINE Liste aller Bild-Anweisungen und einen Kommentar daneben.
Strichfiguren- Gesicht, Animationsprinzipien, neue Captions (dritter Anlauf)
Umgebaut 2026-07-31 nach Merts Urteil "immernoch Kinderkacke" plus einem Screenshot der fallenden Figur (sah aus wie eine gerissene Marionette) und "die captions sind auch fuerchterlich". Vorher wurde nachrecherchiert- Alan Beckers Anleitung zur Strichfiguren-Animation, eine Stick-Figure-Masterclass, die Caption-Praxis für Kurzvideos. 1. DIE ANIMATIONSPRINZIPIEN HABEN GEFEHLT. Becker woertlich- "bei JEDER grossen Bewegung muss es vorher eine Bewegung in die Gegenrichtung geben" (Ausholen) und "wenn eine grosse Bewegung stoppt, geht man ein Stück über den Endpunkt hinaus und dann zurück" (Ueberschwingen). Die Uebergaenge blendeten geradlinig weich von Pose zu Pose — genau daran erkennt man "geschoben" statt "gezeichnet". Jetzt- Ausholen (-12 %), Ueberschwingen (+10 %, gedaempfte Feder), Nachziehen (Huefte fuehrt, Kopf folgt, Arme kommen zuletzt an) und ein winziger Nicker auf jedes Text-Haeppchen (sekundaere Aktion). Alles skaliert mit der Größe des Posenwechsels- bei fünf Grad waere Ausholen ein Zucken. 2. DIE FIGUR HAT EIN GESICHT UND EIN ERKENNUNGSZEICHEN. Augen, Brauen, Mund; acht Mimiken in posen.json, jede Pose bringt ihre passende mit, [gesicht:froh] ueberschreibt sie, und die Mimik blendet beim Szenenwechsel mit. DIE BRAUEN tragen den Ausdruck, nicht der Mund. Dazu eine Haarlocke als Alleinstellungsmerkmal- EIN Strich, aber er macht aus "irgendein Strichmaennchen" DIESE Figur. Beides von Mert angestossen und von der Recherche gedeckt- die Masterclass nennt die Fehlpaarung von Mimik und Aussage als Hauptkritikpunkt an KI-Figuren und Eigenstaendigkeit als den Unterschied zwischen wachsenden und untergehenden Kanaelen. 3. CAPTIONS KOMPLETT NEU. Vorher- ganzer Satz klein am unteren Rand PLUS ein grosses Wort oben, das erst erschien, wenn es gesprochen wurde. Bei einem Satz mit Schluesselwort am Ende stand die halbe Bildflaeche sekundenlang leer, und der Satz war zu klein zum Lesen. Jetzt EIN System- Haeppchen von hoechstens drei Woertern, 94 px fett, im unteren Mitteldrittel, auf die Wortzeiten gesetzt, ein Wort je Satz farbig, heller Rand für Lesbarkeit über der Figur. 39 Einblendungen statt 13 statischer Sätze. DER FEHLER HINTER ALLEN DREIEN, und das ist die eigentliche Lehre- EINE Rechercheaussage ("es wirkt, wenn es ruhig und stetig ist") wurde zur Bauregel, und daraus folgte "die Figur steht still, braucht kein Gesicht, braucht keine grossen Captions". Die zweite Quelle sagt das Gegenteil- "Diese Videos haben deutlich mehr Bewegung, als man denkt. Wer statische Videos mit stillstehenden Strichmaennchen macht, schiesst sich selbst ins Knie." EINE Quelle ist keine Recherche.
Zwischenschritt- Strichfiguren bewegen sich überhaupt
Umgebaut 2026-07-31 nach Merts Urteil zum ersten Reel- "das ist keine Animation, das sind 3 Zeichnungen ganz billig hintereinander gereiht". Er hatte recht- je Szene wurde EIN Bild gezeichnet und bis zu sieben Sekunden gehalten. DER DENKFEHLER, und er ist lehrreich für jede kuenftige Reel-Art- Aus einem Rechercheergebnis ("es wirkt, wenn es ruhig und stetig ist") wurde eine Bauregel ("die Figur steht still"). Gemeint war- keine hektischen Effekte, keine harten Schnitte. NICHT- ein eingefrorenes Standbild. Eine Figur, die sich gar nicht bewegt, ist kein ruhiges Video, sondern ein Foto. Eine Rechercheaussage ist eine Richtung, keine Bauvorschrift — wer sie woertlich in Code giesst, kommt am anderen Ende heraus. WAS JETZT LÄUFT (bewegung.py, drei Ebenen)- LEERLAUF, jede Pose atmet und verlagert das Gewicht um wenige Grad; ZYKLUS, gehen/rennen/winken haben echte Schluesselbilder in posen.json und laufen sie in der Schleife; UEBERGANG, zwischen zwei Szenen wird ueberblendet statt geschnitten — der größte Einzelgewinn, weil aus dreizehn Bildern EINE Figur wird, die dreizehn Dinge tut. Dazu kocht der Strich (alle zwei Bilder neu ausgewuerfelt), wie jedes Blatt einer echten Zeichentrickfolge. 12 ZEICHENBILDER JE SEKUNDE, nicht 30- gezeichnete Animation läuft klassisch "auf Zweier". 30 saubere Zwischenschritte sehen nach Rechner aus, 12 nach Hand. Das Video bleibt 30 Bilder/s. MÖGLICH IST DAS NUR, weil eine Pose aus WINKELN besteht statt aus einem Bild — zwischen zwei Bildern kann man nicht ueberblenden, zwischen zwei Winkeln schon. Die Funktion dafür (figur.mischen) gab es von Anfang an und wurde bewusst nicht benutzt. WAS ES KOSTET- 623 statt 169 Bilder je Reel. Aufgefangen durch zwei Messungen- nur noch den Ausschnitt zeichnen, in dem die Figur steht (212 -> 30 ms je Bild), und PNG mit compress_level=1 (653 -> 154 ms, verlustfrei). Die Renderzeit blieb bei rund drei Minuten. BELEG, dass sich wirklich etwas bewegt- dieselbe Laenge und dieselben Encoder-Einstellungen liefern jetzt 711 statt 468 kbit/s. NEUES WERKZEUG- "blatt.py --bewegung gehen" bzw. "--bewegung zeigen,fallen" zeigt Zyklus oder Uebergang als Bildstreifen. Vorher sah man Bewegung erst nach einem Cloud-Lauf. Es fand sofort einen Fehler- die Arme schwangen quer über den Koerper (ein Seitenansichts-Gang an einer von VORN gezeichneten Figur) und sahen aus wie verschraenkt.
Ein fertiges Reel ist kein Beweis — das erste Strichfiguren-Video war komplett falsch
Passiert 2026-07-31 beim ersten erfolgreichen Cloud-Lauf der Strichfiguren. WAS HERAUSKAM: ein vollstaendiges, abspielbares Reel. 1080x1920, 52 Sekunden, 30 Bilder/s, sauberer Ton, richtige Schrift, Text an der richtigen Stelle. Nichts war rot, keine Fehlermeldung, keine Warnung. WAS FALSCH WAR: Keine einzige der dreizehn Posen aus dem Skript war angekommen. Alle dreizehn hatte die Maschine geraten, alle Requisiten waren verloren. Das Reel zeigte die richtigen Sätze zu zufaelligen Figuren. URSACHE: render() wertete das Skript aus und gab dann das BEREINIGTE Skript an die Planung weiter, die es ein zweites Mal auswertete. Im bereinigten Text stehen keine eckigen Klammern mehr — die zweite Auswertung griff zwangslaeufig ins Leere. WIE ES AUFFIEL, und das ist der eigentliche Punkt: an EINEM fehlenden Fragezeichen im Vorschaubild. Nicht an einer Fehlermeldung. Der einzige Grund, warum es sich danach in zwei Minuten belegen liess statt in zwei Stunden, war die Protokollzeile "13 von 13 Posen GERATEN", die der Rueckfall über sich selbst schreibt. DREI LEHREN, die für jedes Format hier gelten: (1) Ein Rueckfall MUSS sich selbst melden. Die Regel stand vorher schon in CLAUDE.md; hier hat sie zum ersten Mal nachweislich einen Fehler gerettet, der sonst durchgegangen waere. (2) Nach einem Cloud-Lauf gehört das PROTOKOLL gelesen, nicht nur die Datei geprüft. Die Datei war in jeder messbaren Hinsicht in Ordnung. (3) Behoben wurde nicht der Fehler, sondern seine Möglichkeit: plane() nimmt jetzt die fertigen Beats statt eines Textes. Es gibt keine zweite Auswertung mehr, die falsch liegen könnte.
Strichfiguren: die Figur ist DATEN, nicht Bild — und sie steht still
Gebaut 2026-07-31 als Geruest der Reel-Art (available noch False). ENTSCHEIDUNG 1 — POSEN ALS ZAHLEN IN EINER JSON-DATEI. Eine Figur ist ein Satz Gelenkwinkel in posen.json, sonst nichts. Daraus zeichnet Python das Video (Pillow) UND der Browser die Vorschau (SVG). Zwei Zeichner, EINE Wahrheit: waeren die Posen doppelt hinterlegt, würde die Vorschau irgendwann etwas anderes zeigen als das fertige Reel — und das faellt erst am fertigen Video auf. Nebenwirkung, die den Ausschlag gab: eine neue Pose ist ein JSON-Eintrag, keine Codeaenderung. Spiegeln kostet nichts (alle Winkel negieren), die Bibliothek ist also doppelt so gross wie sie aussieht. ENTSCHEIDUNG 2 — DIE FIGUR BEWEGT SICH NICHT. Sie wird in rund einer halben Sekunde GEZEICHNET (man sieht den Strich entstehen) und steht danach still. Das ist keine Sparmassnahme, sondern das Format: in der Recherche ist genau dafür ein Kanal zerlegt worden — "constant motion effects, und das geht gegen das, was dieses Format ausmacht; es wirkt, wenn es ruhig und stetig ist". Nebenbei kostet es statt 1200 Einzelbildern je Reel rund 15 je Szene. figur.mischen() könnte Posen ueberblenden und wird bewusst nicht benutzt. ENTSCHEIDUNG 3 — DAS GROSSE WORT IST EINE TEXTEBENE, KEIN GEMALTES BILD. Ins Szenenbild gemalt müsste es mit dem Szenenanfang erscheinen, also bis zu zwei Sekunden zu frueh. Als ASS-Ebene sitzt es auf der Millisekunde des gesprochenen Wortes. GENAU DARIN LIEGT DER VORSPRUNG: Beide ausgewerteten Tutorials bestehen im Kern aus derselben Handarbeit — Tonspur ins Schnittprogramm, an jedem Satz zerschneiden, Figur draufziehen, Zeitpunkt von Hand nachschieben. Eine halbe Stunde je Reel. ReelForge kennt die Wortzeiten auf rund 90 ms. ENTSCHEIDUNG 4 — REGIE STEHT IM SKRIPT, NICHT IN EINER ZWEITEN DATEI. "[pose:nachdenken] Satz." Bei Vox beschreibt drehbuch.yaml Bildmotive für ein Bildmodell, da geht kein Weg dran vorbei; hier ist die Bildinformation EIN Wort. Zwei Dateien, die zeilenweise zueinander passen müssen, laufen auseinander, sobald jemand einen Satz einfuegt — und dann sind ALLE Posen um eins verschoben, was man dem Video nicht ansieht. Ohne Angabe wird die Pose aus dem Satz geraten, das steht aber im Protokoll ("3 von 5 Posen GERATEN") — kein stiller Rueckfall. WAS DAS FORMAT KOSTET: nichts ausser der Sprecherstimme. Keine Bilder, kein Filmmaterial, keine Lizenzfragen — und es traegt genau die abstrakten Themen (Psychologie, Philosophie), an denen die Archiv-Doku ausfaellt. ZWEI FEHLER, DIE BEIM BAUEN ZUGESCHLAGEN HABEN und als Warnung hier stehen: (1) Bei der Ueberabtastung wurde die Position mit dem Faktor multipliziert, die Figurenhoehe aber nicht — Ergebnis war eine halb so grosse Figur an der richtigen Stelle, die sauber gezeichnet aussah. Man sucht den Fehler danach im Layout. (2) Das Zittern des Strichs wurde je Teilstueck neu gewuerfelt statt als weiche Welle über den ganzen Strich — das sieht nicht handgezeichnet aus, sondern klumpig. Beides faellt nur am Bild auf, nirgends wird etwas rot. Deshalb: nach JEDER Änderung an posen.json oder figur.py "python3 -m formate.strichfiguren.blatt" laufen lassen und hinschauen.
Archiv-Doku auf Eis — Mert: 'null catchy'. Nächstes ist der Strichfiguren-Erklaerer
Entschieden von Mert am 2026-07-31, nachdem er die Vorschau des ersten Reels (Hundekopf-Wiederbelebung, Sowjetunion 1940) gesehen hat: "tote idee, das ist null catchy". Die Kette ist technisch VOLLSTAENDIG und funktioniert — sie wird nicht gelöscht, sondern liegt still (available: False). Gebaut wird stattdessen die vorgemerkte Idee 2, der Strichfiguren-Erklaerer. EINWAND, DER GESAGT WURDE UND NICHTS GEÄNDERT HAT: Beurteilt wurde aus einer Vorschau, die ausdruecklich KEINE Bewegung zeigt (Standbilder statt Filmausschnitte, kleine Vorschaubilder statt 640x480). Bei "catchy" traegt Bewegung viel. Merts Entscheidung steht trotzdem — und die Gegenthese ist plausibel: koerniges Wochenschaumaterial gegen saubere Animation ist auf TikTok ein harter Kampf. WAS AUS DIESER ARBEIT BLEIBT UND WEITER BENUTZT WIRD: (1) vox.schnitt/vox.bau können Clips an beliebiger Stelle einsteigen lassen ("03_ab12_name.mp4") — rueckwaertskompatibel, Vox unveraendert. (2) vox.wolke kann beliebige Formate in der Cloud rendern (art=, zusatz=) statt nur "vox". Jede kuenftige Reel-Art braucht das. (3) archivdoku/vorschau.py — Reel im Browser ansehen VOR dem Schnitt, mit echtem Ton. Das ist formatunabhaengig gedacht und sollte für die Strichfiguren mitbenutzt werden; es beantwortet genau die Frage, an der die Archiv-Doku gescheitert ist, und zwar BEVOR Rechenzeit und Kontingent draufgehen. (4) Die Erkenntnis, dass ein neues Format einmalig ein Render-Ausrollen braucht. LEHRE FUERS NÄCHSTE FORMAT: Die Vorschau haette früher kommen müssen — vor dem Skript, nicht nach Material, Sprecher und Musik. Ein Format, das nicht traegt, faellt so nach zehn Minuten auf statt nach einem halben Tag.
Archiv-Doku: der Einstiegspunkt steht im DATEINAMEN, und ohne ihn wird abgebrochen
Gebaut 2026-07-31, letztes fehlendes Glied der Kette (holen.py). DAS PROBLEM, gemessen im ersten vollstaendigen Durchlauf: Von fünf gewaehlten Treffern war einer eine 45-Sekunden-Wochenschau — die anderen vier liefen 13, 14, 19 und 45 MINUTEN. Für Szenen von je fünf Sekunden. Lange Archivrollen beginnen mit Verleihlogo, Vorspann und Titel; der Cutter nahm bisher immer den ANFANG eines Clips (richtig für Vox, wo ein bestelltes 3-Sekunden-Clip ab der ersten Sekunde das ist, was man wollte). Drei der fünf Szenen haetten damit SCHRIFT statt Motiv gezeigt — und das Reel waere fertig und abspielbar gewesen. LÖSUNG 1 — der Einstieg steht im Dateinamen: "03_ab12_rakete.mp4" heißt ab Sekunde 12. Nicht in einer beigelegten Datei, weil der ganze Vertrag zwischen Format und Schnitt "ein Ordner, je Szene eine Datei, alphabetisch" ist und der Ordner als Ganzes in die Cloud geht: was NEBEN der Datei liegt, kann sich von ihr loesen, im Namen kann es das nicht — und man sieht es beim Blick in den Ordner. Gelesen wird es von vox.schnitt.AB_MUSTER, umgesetzt in vox.bau (ffmpeg -ss VOR -i, also schnelles Suchen über den Index statt Durchdekodieren). Ohne "_abN_" ist der Wert 0 — Vox merkt von der Änderung nichts. LÖSUNG 2 — harter Abbruch statt Warnung: Nimmt eine Szene einen Film über drei Minuten ab Sekunde 0, bricht holen.py ab und nennt die betroffenen Szenen mit Laufzeit. Eine Warnung waere hier zu wenig gewesen: der Fehler erzeugt kein Fehlerbild, sondern ein fertiges Reel mit Filmtiteln drin. Uebersteuerbar mit --vorspann-egal, falls der Anfang ausnahmsweise stimmt. NICHT GEBAUT und bewusst so: kein eigener Zuschneide-Schritt. Der Schnitt in der Cloud kuerzt jede Szene ohnehin auf ihre Laenge und muss nur wissen, wo er einsteigt. Zuschneiden auf dem Pi waere außerdem Rendern und damit gesperrt. OFFEN: 507 MB für fünf Szenen. Kurze Beitraege (Wochenschauen) sind das passendere Material, aber die Laufzeit steht NICHT im Suchindex des Archivs (geprüft: das Feld runtime ist leer) — sie im Kontaktbogen anzuzeigen kostet eine Extra-Anfrage je Vorschlag, also rund 60 je Reel. Bis dahin faellt die Laufzeit erst beim Holen auf.
Zielplattform: TikTok zuerst, YouTube und Instagram nebenher
Entschieden von Mert am 2026-07-31: Die Reels gehen hauptsaechlich auf TikTok, werden aber auch auf YouTube und Instagram gestellt ("kostet ja nichts"). Das stimmt fuers Hochladen — dieselbe Datei, 1080x1920 passt ueberall. Drei Folgen sind aber NICHT gratis und deshalb hier festgehalten: (1) DER SICHERE BEREICH IST AUF DIE FALSCHE PLATTFORM EINGESTELLT. Die Werte in caption_engine.py stammen aus Instagrams Angaben. Oben, unten und links ist Instagram strenger als TikTok, das deckt also mit ab — aber rechts verlangt TikTok 120-140 px für seine Knopfleiste, gesperrt sind nur 90. Die breitesten Zeilen ragen darunter. Als Aufgabe erfasst, Änderung gehört der Session "Reelforge" (gemeinsame Datei). (2) NIE DAS FERTIGE VIDEO VON TIKTOK HERUNTERLADEN und woanders hochladen — das traegt TikToks Wasserzeichen, und die anderen Plattformen druecken solche Videos in der Reichweite. Immer die Originaldatei aus ReelForge auf jede Plattform einzeln laden. (3) DAS HOCHLADEN NACH TIKTOK IST HANDARBEIT. instapi kann TikTok bisher nur für Interaktion (tiktok_engage.py), nicht zum Veroeffentlichen. Bei einer Reel-Art, die auf taegliches Posten ausgelegt ist, wird das der Engpass — nicht das Bauen.
Herkunftsnachweis je Reel — Nennungspflicht und Schutz vor falschen Anspruechen
Eingebaut 2026-07-31 mit der Archiv-Doku (quellen.herkunft_schreiben). Beim Zusammenstellen des Szenen-Ordners entsteht eine HERKUNFT.txt samt herkunft.json: je Szene Quelle, Titel, Lizenz, Urheber, Fundstelle — und daraus erzeugt ein Block mit den Nennungen, die in die Videobeschreibung gehören. ZWEI GRUENDE, BEIDE KONKRET: Erstens verlangen die CC-Lizenzen mit "BY" (die Mehrheit bei Openverse, auch die NASA-Fotos) die Nennung von Urheber und Lizenz. Kostenlos heißt nicht bedingungslos — ein Reel ohne Nennung verstoesst gegen die Lizenz. Zweitens melden sich auf YouTube für gemeinfreies Archivmaterial regelmäßig angebliche Rechteinhaber, meist weil jemand eine restaurierte Fassung angemeldet hat. Gemeinfreies Material ist als Grundlage solcher Ansprueche ausdruecklich nicht zugelassen, ein Widerspruch hat also gute Aussichten — aber nur, wenn man binnen Frist belegen kann, woher der Ausschnitt stammt. WARUM BEIM ZUSAMMENSTELLEN UND NICHT BEIM RENDERN: sonst fehlt der Nachweis für jedes Reel, das nie fertig wurde — und die Quelle hinterher zu rekonstruieren ist genau die Arbeit, die dann niemand mehr leistet.
Nächste Reel-Art: Archiv-Doku — echtes Filmmaterial statt KI-Bildern
Entschieden 2026-07-31 nach einer YouTube-Recherche zu automatisierbaren Reel-Arten ohne KI-Bilder (Merts Vorgabe). Statt zwoelf Bilder bei OpenArt zu bestellen, holt die Kette je Szene echtes, frei lizenziertes Material: Internet Archive (gemeinfreie Filmrollen), Openverse (800 Mio. CC-Werke, API OHNE Schluessel), Pexels optional. Beide Hauptquellen am 2026-07-31 live gegen die echte API geprüft, nicht nur behauptet. WARUM DIESE ART ZUERST: Der Vox-Schnitt ist materialunabhaengig — sein ganzer Vertrag ist "ein clips/-Ordner, je Szene eine Datei, alphabetisch sortiert" (schnitt.py). Bilder bekommen eine Kamerafahrt, Videos laufen wie sie sind. Es braucht also KEINEN neuen Renderer, nur einen neuen Weg, diesen Ordner zu fuellen. Damit sind rund 80 % der Kette (Skript, Sprecher, Wortzuordnung, Schnitt, Textstempel) schon gebaut. DER HEBEL: Kosten je Reel fallen von rund 560 Credits auf nahe null. Der teuerste Posten der Vox-Kette ist Bewegung (2 Clips a 42 Credits) — echtes Filmmaterial bringt seine Bewegung mit. Das trifft zugleich einen gemessenen Formatfaktor: in der ausgewerteten Stichprobe viraler Shorts bewegt sich fast immer schon in der ersten Millisekunde etwas, ein Standbild am Anfang ist die Ausnahme. EHRLICHE GRENZE, DAMIT SIE NIEMAND SPÄTER ENTDECKT: Die automatische Suche liefert oft Unbrauchbares. Das wird bewusst ein HALB automatisches Format — die Maschine schlaegt je Szene mehrere Clips vor, ein Mensch wählt. Und es traegt nur Themen, die jemand gefilmt hat (Raumfahrt, Krieg, Industrie, Zeitgeschichte); für Psychologie oder Philosophie faellt es aus — dafür ist die Strichfiguren-Idee gedacht. VERWORFEN wurde das meistempfohlene Format aus der Recherche (Reddit-Geschichte oben, Gameplay unten): Das Material ist fremdes Eigentum, und die Auswertung dazu misst bei geteiltem Bild 30 % schlechteres Behalten — für ein Erklaer-Format der Tod der eigentlichen Wirkung.
Vorgemerkte Reel-Art: Strichfiguren-Erklaerer, vom Rechner gezeichnet
Festgehalten 2026-07-31 als die eigentlich neue Produkt-Idee — noch NICHT gebaut, bewusst hinter der Archiv-Doku eingereiht (Merts Entscheidung: erst der schnelle Hebel, dann das eigene Produkt). WAS ES IST: Der minimalistische Erklaer-Stil mit Strichfiguren, wie ihn Kanaele im Psychologie-/Philosophie-Bereich fahren. Belegt, nicht geraten: ein Kanal in diesem Stil kam laut Recherche in 90 Tagen auf 20 Mio. Aufrufe, in der Nische liegen einzelne Videos über 1 Mio., Publikum vor allem 18-24. WARUM ES FUNKTIONIERT (die Begruendung ist der Grund, nicht die Zahl): Strichfiguren senken die Denklast. Kein Gesicht lenkt ab, der Zuschauer hängt am Inhalt statt an der Person. WARUM ES ZU REELFORGE PASST WIE NICHTS SONST: Solche Figuren werden GEZEICHNET, nicht generiert — also von Code. Das ist genau die Staerke, die hier schon steht (die Caption-Engine setzt Text auf ~90 ms genau auf den Ton). Keine Materialkosten, keine Rechtefragen, jedes Thema möglich — auch abstrakte, an denen die Archiv-Doku scheitert. EHRLICHE KOSTEN: der teuerste Bau der drei geprueften Ideen. Eine Figurenbibliothek und ein Bewegungssystem sind grob zwei bis drei Wochen, nicht zwei Tage. Genau deshalb steht die Archiv-Doku davor. DRITTE, NICHT GEWAEHLTE IDEE (der Vollstaendigkeit halber): Rangliste/Zahlen-Reel, reine Typografie, vollautomatisch, null laufende Kosten, starker Kommentar-Treiber — aber Massenware, in einer Woche nachgebaut. Als Kommentar-Maschine jederzeit nachrueckbar, als Aushaengeschild ungeeignet.
Reparatur des abgerissenen Schlusses gilt jetzt für ALLE Formate
Hochgezogen 2026-07-31 aus formate/vox/zuordnen.py nach caption_timing. DER FEHLER: Bei laengeren Aufnahmen bricht die Zuordnung vor dem Ende ab. Die betroffenen Woerter verschwinden nicht — sie bekommen alle das Ende der Tonspur mit Laenge null. Gemessen 2026-07-29: die letzten 13 von 76 Woertern bei 37 Sekunden, 9 von 118 bei 55 Sekunden. Das Protokoll meldete trotzdem "76 Woerter zugeordnet". WARUM ER TROTZ LÖSUNG ZWEI TAGE OFFEN WAR: Entdeckt und geloest wurde er dort, wo er auffiel — in Vox. Entstanden ist er in caption_timing, das ALLE Formate benutzen. Damit hatte ein Format ein Pflaster, während lyrics_std, story_scroll und spotify weiterliefen; bei ihnen waeren die letzten Songzeilen still falsch getimt gewesen, ausgerechnet an der Pointe. Die Vox-Session durfte die gemeinsame Datei nicht anfassen (Revier-Regel) und hat es korrekt als Aufgabe gemeldet — die Regel hat also funktioniert, nur hat zwei Tage lang niemand die Aufgabe aufgegriffen. LEHRE FUERS NÄCHSTE MAL: Wird ein Fehler in einem Format behoben, der im KERN entsteht, ist die Arbeit erst halb fertig. Das Pflaster im Format hilft einem, die anderen laufen weiter hinein — und niemand sieht es, weil ihr Protokoll Vollzug meldet. Die Reparatur ist jetzt standardmaessig AN, damit kein Format sie vergessen kann. formate/vox/zuordnen.py bleibt als duenne Huelle (übrig ist dort nur noch die Vox-eigene Entscheidung "keine Stimmentrennung"), damit die uebrigen Vox-Dateien unveraendert weiterlaufen. EINE VERBESSERUNG BEIM HOCHZIEHEN: Das Nachlegen bekommt jetzt DIESELBEN Einstellungen wie der Hauptlauf, also bei Musik MIT Stimmentrennung. Vox reichte sie nicht durch — dort egal (Vox trennt ohnehin nicht), für Musik waere es ein stiller Qualitaetsabfall gewesen: reparierter Schluss auf dem vollen Mix (230 ms Versatz), Rest des Songs auf der isolierten Stimme (90 ms). Die letzten Zeilen waeren sichtbar hinterhergelaufen, ohne dass ein Protokoll etwas gemeldet haette. GEPRÜFT: 13 Logik-Tests (Abriss-Erkennung inkl. Abgrenzung gegen echte Null-Laengen-Woerter mittendrin, Zusammensetzen, Reihenfolge, Durchreichen der Trennung, lauter Fehler bei falscher Wortzahl und bei unreparierbaren Resten). Reine Rechnung ohne Ton — der Volllauf mit echtem Audio steht noch aus, siehe tasks.
Die Caption-Messungen laufen in der Cloud — der Pi rendert nicht mehr mit
Umgestellt 2026-07-31. caption_check.py und caption_vorlage.py rendern mit ffmpeg echte Standbilder und ziehen Minuten CPU. Das faellt unter Merts harte Regel "auf diesem Pi wird nichts gerendert" — trotzdem stand in ausrollen.sh schlicht "python3 caption_check.py". Damit hat JEDES Ausrollen auf dem Pi gerendert, mit demselben Muster, das am 30.07. den harten Reset des ganzen Boards ausgeloest hat. NEU: cloudbuild.prüfen.yaml nimmt das fertige Render-Abbild als Umgebung (ffmpeg, Schriften, Pakete sind darin) und fuehrt darin den frisch hochgeladenen Code aus — also den ABGELEGTEN Stand, nicht den Arbeitsordner, aus demselben Grund wie beim Bauen. Bedient wird es mit "./ausrollen.sh prüfen"; ausrollen.sh ruft es selbst auf. WARUM NICHT EINFACH EINE WARNUNG: Die Regel stand bereits in Fettschrift mit Verbotszeichen in der globalen CLAUDE.md, samt Schilderung des Resets — und wurde trotzdem uebergangen, weil der lokale Aufruf der kuerzeste Weg war. Ein kurzer Weg gewinnt gegen einen Merksatz. Deshalb ist der erlaubte Weg jetzt der bequeme. GRENZE: Die Pakete kommen aus dem Abbild, also aus dem Stand des letzten Unterbaus. Wer requirements.txt anfasst, prüft gegen alte Pakete — erst "unterbau", dann messen. NACHGEZOGEN am selben Tag: Das Cloud-Build-Protokoll verschluckt bei viel Ausgabe Zeilen — ein Lauf zeigte 201 Messzeilen statt 264, und ob wirklich weniger gemessen wurde oder nur weniger ankam, liess sich nicht nachzaehlen. Für einen Pruefstand der schlechteste Zustand: "Alles sauber" ohne belegbaren Umfang; ein Lauf über die halbe Menge saehe genauso aus. caption_check druckt deshalb am Ende EINE Zeile mit der Zahl gemessener Bilder ("Umfang: 264 Bilder gemessen (8 Stile × 7 Sätze × 3 Gruende, 0 davon leer)"). Eine Zeile geht praktisch nie verloren. ZUSÄTZLICH eine technische Sperre, pi-weit: /home/pi/scripts/kein_rendern_auf_dem_pi.sh hängt als Hook in ~/.claude/settings.json und blockiert ffmpeg-Aufrufe, lokale whisper/demucs/moviepy-Laeufe und die heimlich rendernden Pruefskripte — mit Nennung des erlaubten Weges in der Fehlermeldung. ffprobe und "ffmpeg -version" bleiben frei, ebenso das Suchen nach dem Wort in Dateien. 19 Testfaelle, darunter der Aufruf, der am 31.07. durchgerutscht ist ("timeout 900 python3 caption_check.py") — der wurde vom ersten Entwurf der Sperre NICHT erkannt, weil das Praefix "timeout 900" das Muster brach. Der Selbsttest hat es gefunden; ohne ihn waere eine Sperre ausgeliefert worden, die genau den Anlassfall durchlaesst.
Captions gehen weich weg und haben eine Glut
Gebaut 2026-07-31 aus einer YouTube-Recherche zu Caption-Looks. ZWEI Änderungen an caption_engine.py: (1) WEICHES VERSCHWINDEN — bis dahin stand bei jedem Wort nur "end = Gruppenende", libass schaltete es von einem Bild aufs nächste ab. Eingeblendet wurde über eine Kurve, ausgeblendet gar nicht; im Video wirkt das wie ein Schnitt. Jetzt laufen Deckkraft und Unschaerfe gemeinsam hoch. Faellt weg, wenn ein Wort zu kurz vor dem Gruppenende einsetzt — sonst zuckt es, statt zu gehen. (2) GLUT — eine zweite, unscharfe Kopie jedes Wortes auf tieferer Ebene, Kontur in der Textfarbe. ASS kennt kein echtes Leuchten, so macht man es. Beide über die Stil-Sätze abschaltbar (aus_dauer_ms=0 bzw. glut=0 stellt exakt den alten Stand her). FOLGEARBEIT am Pruefstand, sonst haette er Fehlalarm geschlagen: kollisionen() lässt Glut-Stile aus (sie liegen per Bauart genau auf ihrem Wort), und zeitpunkte() fotografiert nicht mehr 80 ms vor Schluss, sondern vor Beginn des Ausblendens — sonst misst man ein halb aufgeloestes Wort und bekommt "Kontrast 0" für ein Bild, an dem nichts falsch ist. Die Dauer wird aus der Engine abgeleitet, nicht doppelt gepflegt. STAND 2026-07-31: abgelegt und DURCHGEMESSEN in der Cloud (Stand 2c8df46, Abbild render:v18) — alle drei Schritte gelaufen, 264 Kaesten gemessen, "Alles sauber", Vorlagen-Abweichung 1,2 % von 2 % erlaubt, also unveraendert gegenueber vorher: der Held-Look ist durch Ausblenden und Glut NICHT abgedriftet. Der erste Messlauf war rot und hat zwei echte Fehler gefunden, siehe den Eintrag "sicherer Bereich stand doppelt". VERWORFEN: ein abdunkelnder Verlauf hinter dem Text (Scrim), wie ihn CapCut-Tutorials zeigen. Der Pruefstand misst Kontrastwerte von 128 bis 241 bei einer Schwelle von 65 — er würde ein Problem loesen, das nicht existiert, und dabei die Messung blenden: eine dunkle Fläche zählt für caption_check als Text und verfaelscht Kasten, Fläche und Lage. Vox hat einen Scrim, weil dort andere Gruende gelten.
Sicherer Bereich nach Instagrams Bedienelementen statt nach Gefuehl
Korrigiert 2026-07-31 in caption_check.py. Vorher ein gleichmaessiger Rahmen (0,055/0,945 und 0,115/0,860); der Kommentar sprach schon von Bedienelementen, die Zahlen taten es nicht. Gefaehrlich war die untere Kante: sie lag bei 1651 px, die Beschreibungs- und Tonzeile von Instagram reicht aber bis 1520 px herauf — Text durfte also 131 px weit in einen Bereich stehen, der im fertigen Reel zugedeckt ist. Am gerenderten Bild sieht man das NICHT, die Bedienelemente kommen erst auf dem Handy dazu. Neu: oben 250 px (Name/Zeit), unten 400 px (Beschreibung, Ton, Fortschritt), rechts 90 px (Knopfleiste); links bleibt reiner Randabstand. ⚠️ HERKUNFT: aus Instagrams Flaechenangaben, NICHT selbst am Geraet nachgemessen — in diesem Projekt der schwaechere Beleg, deshalb steht es im Code ausdruecklich dran. Gegenprobe als Aufgabe für Mert eingetragen. NACHTRAG: Die Werte standen anfangs nur im Pruefstand, während die Engine weiter nach den alten hartkodierten Grenzen setzte — der erste Messlauf hat das prompt aufgedeckt. Sie stehen jetzt in caption_engine.SICHER_X/SICHER_Y und sonst nirgends.
Ausgerollt wird der abgelegte Stand, nicht der Arbeitsordner
Umgestellt 2026-07-30 auf Merts Frage, ob die Reel-Arten nicht unabhängig voneinander ausgerollt werden könnten. ANTWORT ZUERST, weil sie ein Missverstaendnis ausraeumt: Unabhängig gebaut sind das ARBEITEN (eigene Session, eigenes Revier), das TESTEN (vorschau <name> gibt eine eigene Cloud-Adresse, ohne Merts Verkehr umzuleiten) und die SICHTBARKEIT (available=False). NICHT das Ausrollen — es gibt genau EINEN Oberflaechen-Dienst und EINEN Render-Job, beide aus dem gesamten Ordner gebaut. Ein Ausrollen je Reel-Art gibt es nicht und gab es nie; dafür braeuchte es getrennte Dienste je Format, was den Aufwand nicht wert ist. WAS SICH GEÄNDERT HAT: Gebaut wird jetzt aus dem zuletzt abgelegten Stand (git archive HEAD in einen Temp-Ordner), nicht mehr aus dem Arbeitsordner. Vorher lud "gcloud builds submit" den Ordner hoch, wie er gerade dalag — samt halb getippter Dateien anderer Sessions. Das sieht man dem Abbild nicht an und faellt fruehestens im fertigen Video auf. Merts Bedingung war ausdruecklich, dass die laufende Vox-Arbeit dabei nicht gelöscht oder abgebrochen wird; genau deshalb kein stash und kein checkout — der Arbeitsordner wird überhaupt nicht angefasst, nur kopiert wird der abgelegte Stand. Trockenprobe bestaetigt: 115 Dateien im Bau, alle Schriften und Vorschaubilder dabei, Vox-Dateien in der ABGELEGTEN Fassung, und der Arbeitsordner danach unveraendert. NEUE FALLE IN DIE ANDERE RICHTUNG, deshalb mit umgebaut: wer seine EIGENE Arbeit nicht abgelegt hat, rollt aus und wundert sich, dass sich nichts geändert hat. Die Nachfrage vor dem Ausrollen warnt jetzt nicht mehr vor Gefahr, sondern sagt an, WAS ausgeliefert wird (Commit-Nummer und -Titel) und was nicht. NICHT GELOEST: abgelegte, aber unfertige Arbeit einer anderen Session geht weiterhin mit raus. Dagegen hilft nur available=False. Ebenfalls offen: die Pflichtpruefungen laufen weiter im Arbeitsordner, prüfen also unter Umstaenden minimal etwas anderes als das, was ausgeliefert wird. Der Unterschied ist genau die ungespeicherte fremde Arbeit — waere die kaputt, bricht die Prüfung ab und es wird nichts ausgerollt. Also die sichere Richtung, aber bewusst so und hier notiert. NACHTRAG NOCH AM SELBEN TAG, beim ersten echten Ausrollen aufgefallen: der Stand wurde ZWEIMAL gelesen — einmal für die Ansage, einmal beim Bauen. Die Pflichtpruefungen dauern rund drei Minuten, und genau in dieser Zeit hat die Vox-Session etwas abgelegt. Angesagt war 241a4c4, gebaut wurde da9e866. Diesmal harmlos (Vox steht auf available=False), aber die Bauart war falsch: haette der fremde Commit ZWISCHEN den beiden Bauschritten gelegen, waeren Oberflaeche und Render-Abbild aus verschiedenen Staenden gekommen, ohne dass es jemand sieht. Der Stand wird jetzt EINMAL beim Start festgehalten (STAND) und danach nicht mehr neu gelesen.
Zweiter Caption-Look "Plakat" — Blocksatz statt Treppe
Gebaut 2026-07-30 auf Merts Auftrag ("erstelle eine weitere Variante, die sich vom Held abhebt — die mit wichtigste Sache ist die Anordnung und die Abstaende"). Bewusst ein GEGENENTWURF, kein zweiter Anlauf: Held lebt von Rhythmus (zwei Schriften im Wechsel, ein Wort gross, Treppe nach rechts unten, verzahnte Zeilen), Plakat von Ordnung (EINE Schrift, DM Sans fett, zwei saubere senkrechte Kanten). Etwas Halbes dazwischen haette die Auswahl aufgeblaeht, ohne etwas Neues zu können. DIE DREI REGELN, alle drei über Anordnung und Abstaende: (1) JEDE ZEILE FUELLT DIE BLOCKBREITE, und zwar über die SCHRIFTGROESSE — nicht die Größe steht fest und die Zeile wird, wie sie wird, sondern umgekehrt. Drei kurze Woerter ergeben eine grosse Zeile, zwei lange eine kleine. Der Groessenunterschied ist also nicht gesetzt, sondern eine Folge der Sprache. (2) WO DIE GRÖSSE ANSTOESST, ÜBERNEHMEN DIE ABSTAENDE. Ein einzelnes kurzes Wort müsste sonst absurd gross werden; stattdessen greift ein Deckel und der Rest wird mit Buchstabensperrung und Wortluecken aufgefuellt (die klassische Plakat-Technik). Nachgemessen statt angenommen: libass addiert je Buchstabenzwischenraum exakt den \\fsp-Wert (gegengeprueft am gerenderten Bild — 4,00 Zwischenraeume bei einem Wort aus 5 Buchstaben, über drei Sperrwerte stabil). (3) DER ZEILENABSTAND KOMMT AUS DER ECHTEN TINTE: Unterlaenge der oberen plus Oberlaenge der unteren Zeile plus feste Luft. Eine Zeile ohne Unterlaengen rueckt von selbst naeher heran. Nebeneffekt: es KANN nicht zusammenstossen, das Nachschieben wie beim Held entfaellt. BETONT wird über die Anordnung, nicht über einen Groessensprung: das Kernwort steht ALLEIN auf seiner Zeile und fuellt die Breite für sich. ZWEI FUNDE AUS DEM PRÜFEN, beide im ersten Entwurf noch drin: (a) VIER ZEILEN KIPPEN DEN LOOK. Weil jede Zeile die Blockbreite fuellt, werden bei vier Zeilen alle gleich gross — heraus kommt ein Absatz statt einer Aussage ("vielleicht / verschwinde / ich einfach / heute Nacht"). Deshalb MAX_WOERTER ["plakat"] = 5: mit hoechstens fünf Woertern und drei je Zeile sind rechnerisch nie mehr als DREI Zeilen möglich. Das ist eine Zusicherung, keine Faustregel, und caption_check.pruefe_plakat() haelt sie fest. (b) DIE BETONUNG KONNTE SICH UMDREHEN. Ein langes Kernwort muss klein gesetzt werden, um in die Breite zu passen, während eine kurze Nachbarzeile an ihren Deckel stoesst und GRÖSSER herauskommt als das Wort, auf das es ankommt. Im Bild sieht das nicht nach Fehler aus, sondern nach falscher Aussage. Regel jetzt: erst die Kernzeile setzen, alle anderen bekommen deren Größe als Deckel — nichts wird größer als das Kernwort. Der Pruefstand hat die Regel prompt beim Wort genommen und eine Zeile mit 184 gegen 182 gemeldet; Ursache war, dass der Deckel aus einer Probemessung hochgerechnet wurde und Schriften nicht exakt linear skalieren. Wird jetzt nachgefasst, bis er wirklich haelt. BEWEGUNG: Aufziehen (die Woerter wachsen in ihre Größe hinein), NICHT der Schub von oben des Held-Looks — eine Bewegung quer zu den Kanten würde genau das aufweichen, was den Look ausmacht. Gemessen: 94 Prozent zu Beginn, danach exakt dieselbe Endgroesse wie die bewegungslose Variante (326 zu 326 Pixel). OBERFLAECHE: dritter Schalter "Look" (Held/Plakat). Die Auswahl ist datengetrieben, controls.jsx blieb unveraendert — es mussten nur alle acht Kombinationen aus look x bewegung x farbe existieren, sonst haetten sich Schalter nicht bewegt (nachgeprueft: 0 Luecken). Der Schalter "Schreibschrift" heißt jetzt "Farbe" — im Plakat gibt es keine Schreibschrift, dort faerbt er das Kernwort. Zwei neue Vorschaubilder, mit der echten Engine gerendert; je Look ein eigener Vorschausatz, weil ein Sechs-Wort-Satz im Plakat in zwei Gruppen zerfallen waere.
Satzzeichen stehen nicht mehr im Bild — schneiden die Gruppen aber weiter
Geändert 2026-07-30 auf Merts Ansage, samt seiner Warnung dazu ("vergiss aber nicht, dass die Satzzeichen im System eine Hilfe sind, um zu entscheiden, wann eine Zeile endet"). Genau darin liegt die Falle, und es ist eine REIHENFOLGE-Falle: Satzzeichen sind das verlaesslichste Signal für den Schnitt der Caption-Gruppen — verlaesslicher als jede gemessene Gesangspause, weil sie aus dem getippten Text stammen und nicht aus einer Messung. Wer sie einfach beim Einlesen wegwirft, um sie aus dem Bild zu bekommen, nimmt der Gruppierung ihr bestes Werkzeug; dann entscheidet nur noch die Pause, und Sätze laufen wieder ineinander — exakt der von Mert gemeldete Fehler "gon do. Sag mir nicht dass alles okay". Dem einzelnen Standbild sieht man das NICHT an. DESHALB: abgestreift wird ERST in caption_bridge.baue_untertitel, also NACHDEM die Gruppen geschnitten sind (Funktion ohne_satzzeichen, nur an den Wortenden — "dont" und "Nacht-Fahrt" behalten ihr Zeichen, weil es zwischen Buchstaben steht). Faellt ein Wort dadurch ganz weg, faellt seine Zeit mit heraus, sonst bekaeme jedes Wort dahinter den Einsatz seines Nachbarn. Anfang und Standzeit der Caption kommen weiter aus der ungekuerzten Gruppe. ABGESICHERT mit caption_check.pruefe_satzzeichen(), das BEIDE Seiten zugleich prüft: kein Satzzeichen im fertigen ASS, UND ein Punkt trennt weiterhin die Gruppen (geprüft mit gleichmaessigem Takt, also ohne jedes Pausensignal — trennt es dann noch, kann es nur am Satzzeichen liegen). Beide Haelften gegengeprobt: Abstreifen zurueckgebaut → meldet den Punkt im Bild; Satzzeichen-Signal abgeschaltet → meldet die verlorene Trennung. Voller Pruefstand danach ohne Beanstandung, Vorlagen-Abweichung unveraendert 1,0 Prozent. NICHT betroffen ist Vox: das Format stempelt ganze Sätze ins Bild (formate/vox/text.py) und braucht seine Satzzeichen.
Drei Caption-Pruefungen liefen nur zum Schein — jetzt halten sie auch auf
Gefunden und behoben 2026-07-30 bei einer Durchsicht der kompletten Caption-Kette (Auftrag Mert: "schau dir alles Wichtige zu den Captions an"). Der Look selbst war in Ordnung — beide Pruefwerkzeuge melden "alles sauber", die Abweichung von Merts Vorlage liegt bei 1,0 Prozent. Kaputt war die ABSICHERUNG, und zwar dreifach, jedes Mal nach demselben Muster: die Prüfung existiert, aber niemand zieht Konsequenzen. (1) DIE 2-PROZENT-REGEL GAB ES NICHT. CLAUDE.md schreibt vor, dass ein Held-Look über rund 2 Prozent Abweichung als abgedriftet gilt. Im Code stand dazu nichts: caption_vorlage.py druckte die Zahl und endete IMMER mit Erfolg, ausrollen.sh schaute sie nur an. Es haetten 8 Prozent dastehen können und es waere trotzdem ausgerollt worden. Jetzt: SCHWELLE = 0,02 in caption_vorlage.py, Abbruchcode 1 bei Ueberschreitung und ebenso bei abweichender Zeilenzahl; ausrollen.sh bricht darauf ab. Gegengeprobt mit absichtlich verstelltem Zeilenabstand (3,1 Prozent → Abbruch). Nebenbei: der Bericht braucht das Standbild gar nicht (die Vorlage steht als gemessene Zahlenreihe im Code), nur das Vergleichsbild — vorher hiess "kein Standbild" stillschweigend "nicht pruefbar", also faellt die Prüfung im Container nicht mehr aus. (2) EIN STILLER RUECKFALL, DER SICH FÜR LAUT HIELT. Lässt sich eine Zeile nicht entzerren, schiebt caption_engine sie pauschal nach unten und schrieb das in die Liste VERZAHNUNG_NOTAUSGANG — mit dem Kommentar "wird vom Pruefstand ausgelesen". Wurde sie nie, von niemandem, und gedruckt wurde auch nichts. Jetzt: Warnung ins Fehlerprotokoll beim Auftreten UND Beanstandung im Pruefstand (dito für SKALA_FEHLER, die unlesbaren Schrift-Umrechnungen). Gegengeprobt mit unmöglich gemachtem Entzerren — beide Zeilen werden gemeldet, Abbruchcode 1. (3) FÜNF VON SIEBEN TESTSAETZEN LIEFEN NIE. Vorgabe von caption_check.py waren "kurz" und "referenz"; die uebrigen fünf standen zwar in SÄTZE, wurden aber nur von Hand gefahren. Nicht dabei war ausgerechnet "zwei_zeilen" — der Fall, an dem Mert die ineinanderlaufenden Zeilen gefunden hatte. Jetzt laufen alle sieben als Vorgabe: 108 gerenderte Bilder, 2 Minuten 45 statt 33 Sekunden, ohne Beanstandung. MERKSATZ: Eine Prüfung, deren Ergebnis niemand liest, ist Zierde. Wer hier etwas misst, muss es auch durchsetzen — sonst waere der Aufwand besser gar nicht da, denn er taeuscht Sicherheit vor.
Push läuft automatisch — und Ausfaelle sind sichtbar
Ergaenzt 2026-07-30. Die GitHub-Sicherung hing daran, dass jede Session "git push" tippt; bei mehreren parallel arbeitenden Sessions ist "jemand denkt daran" keine Sicherung. githooks/post-commit schiebt jetzt nach jedem Commit im HINTERGRUND hoch (im Vordergrund hängt sonst jeder Commit ein bis zwei Sekunden daran, ohne Netz minutenlang). Eingeschaltet mit "git config core.hooksPath githooks" — der Haken liegt IM Repo, damit alle Sessions denselben haben. Während Rebase/Merge feuert er nicht, sonst würde jeder Zwischenstand einzeln gepusht. GEGEN DEN STILLEN RUECKFALL: Fehlschlaege landen in /tmp/reelforge_push.log, und "./ausrollen.sh stand" zählt die Commits, die nur lokal liegen. Beides gegengeprueft — der automatische Push ist nachweislich gelaufen (Commit 8edd0a4 landete ohne Handarbeit oben), und die Warnung schlaegt nachweislich an. Ein Push, der lautlos ausfaellt, waere schlimmer als keiner: man haelt sich dann für gesichert. Damit ist die Hub-Instanz für diesen Zweck nicht noetig — kein Cron, keine pi-weite Automatik, alles im Repo.
Alte Render-Abbilder gelöscht — 13 von 16 grossen Schichten sind jetzt Muell
Aufgeraeumt 2026-07-30 auf Merts Freigabe. Weil vor der Abbild-Trennung jeder Bau ohne Zwischenspeicher lief, hatte JEDES der 15 Render-Abbilder seinen eigenen kompletten Satz Schichten — 30,5 GB in der Artifact Registry, rund 3 EUR im Monat. Gelöscht: render:v1 bis v12 und render-base:v1. Behalten: render:v13/v14/v15 als Rueckfall und render-base:v2. Vorher geprüft, dass nichts darauf verweist (der Job läuft auf v15, keine Cloud-Run-Fassung nutzt ein render-Abbild). Die ui-Abbilder wurden ABSICHTLICH nicht angefasst: an ihnen haengen die Cloud-Run-Fassungen, und ohne Abbild lässt sich eine Fassung nicht mehr starten — "./ausrollen.sh zurück" waere kaputt. Sie sind außerdem klein. ACHTUNG BEIM MESSEN: die angezeigte Größe bleibt zunächst bei 30,5 GB. Artifact Registry gibt die Schichten erst später frei; von 16 Brocken über 900 MB sind jetzt nur noch 3 in Benutzung, die anderen 13 warten auf Googles Aufraeumlauf. Wer die Ersparnis prüfen will, muss also später nochmal nachsehen.
Sicherung ausserhalb des Pi: privates GitHub-Repo
Eingerichtet 2026-07-30 (github.com/mertoege/reelforge, privat). Vorher lag die komplette Projektgeschichte auf EINER SD-Karte — Syncthing spiegelt nur die Dateien auf Merts PC, nicht die Versionsgeschichte. Ein Kartenschaden haette jede Entscheidung, jeden Zwischenstand und jede Rueckrollmoeglichkeit mitgenommen; das war das größte Einzelrisiko im ganzen Aufbau und hatte mit Hosting nichts zu tun. VOR dem ersten Push geprüft: keine Schluesseldateien getrackt, kein Treffer für Schluesselmuster (sk-ant-, ghp_, AIza…, PRIVATE KEY, AKIA…) in der GESAMTEN Historie, .env nachweislich nicht im Repo. Ab jetzt gehört "git push" zum Ablegen — ein Commit, der nur auf dem Pi liegt, ist keine Sicherung. Bei mehreren Sessions kann ein Push abgelehnt werden (jemand war schneller): dann "git pull --rebase && git push". WICHTIG in der Anleitung festgehalten: klagt der Rebase über ungespeicherte Änderungen, sind das die einer ANDEREN Session — kein stash/checkout/reset, das löscht fremde Arbeit, die es nirgends sonst gibt. NEBENBEI: gh speichert den Zugangsschluessel im Klartext unter ~/.config/gh. Alle Sessions laufen als Nutzer pi und haben damit denselben GitHub-Zugriff — bewusst so, weil jede Session pushen soll.
Nach einer Vorschau hängt der Cloud-Run-Verkehr an einer festen Fassung
Gefunden 2026-07-30 beim Testen der neuen Vorschau-Adressen. "--no-traffic" schaltet den Dienst von "immer die neueste Fassung" auf "feste Fassung" um. Folge: Jedes weitere Ausrollen baut, meldet Erfolg — und Mert sieht trotzdem den alten Stand. Beim Test tatsächlich eingetreten (Verkehr hing auf reelforge-00023, während ui:v24 erzeugt wurde). ABGESICHERT: ausrollen.sh setzt den Verkehr jetzt ausdruecklich auf die neueste Fassung UND liest nach, ob dort auch das erwartete Abbild läuft — verglichen wird die Pruefsumme, nicht der Name (Cloud Run loest "ui:v25" beim Ausrollen zu "ui@sha256:…" auf; ein Namensvergleich meldet immer einen Unterschied, den es nicht gibt). "./ausrollen.sh stand" zeigt an, ob der Verkehr festhaengt, "vorschau-weg <name>" raeumt eine Test-Adresse ab. Gemessen nach dem Umbau: 8:04 → 1:47 für das Render-Abbild (Bauen 255→93 s, Hochladen 229→14 s).
Render-Abbild zweigeteilt — Ausrollen 8 Minuten → 1-2 Minuten
Umgebaut 2026-07-30, nachdem Mert gefragt hat, warum das Ausrollen so lange dauert. GEMESSEN an render:v14: 4:15 Bauen + 3:49 Hochladen = 8 Minuten für zwanzig Zeilen Python. Ursache: Cloud Build startet jeden Bau auf einer frischen Maschine OHNE Zwischenspeicher, und cloudbuild.yaml sagte nirgends "nimm den letzten Stand". Also wurden jedes Mal torch (191 MB) und drei Sprachmodelle (~700 MB) neu geladen und installiert — und weil dadurch jede Schicht einen neuen Fingerabdruck bekam, wurden anschliessend alle 4,9 GB neu hochgeladen, obwohl 99 % davon unveraendert waren. LÖSUNG: Dockerfile.render.base (Unterbau: Pakete + Modelle, ändert sich selten) und Dockerfile.render (duenne Schicht: nur Projektcode). ABSICHERUNG gegen den klassischen stillen Rueckfall dieses Projekts — neuer Code auf altem Unterbau: der Unterbau traegt einen Fingerabdruck aus requirements.txt + Dockerfile.render.base, die duenne Schicht vergleicht ihn beim Bauen und BRICHT AB, wenn er nicht passt. Verworfen: eigener Server statt Cloud Run. Der Render-Dienst läuft nur Minuten am Tag (8 Kerne / 16 GB, ~10 Cent je Video); eine Dauermaschine kostet 15-30 EUR im Monat und müsste von Hand gepflegt werden — genau die Umgebungsdrift, die hier schon dreimal ein schlechteres Video hat durchgehen lassen.
ausrollen.sh: ein Werkzeug, Pflichtpruefungen inklusive, Vorschau-Adressen je Session
Eingefuehrt 2026-07-30. Vorher war Ausrollen eine Handvoll langer gcloud-Zeilen mit von Hand hochgezaehlten Nummern. Jetzt: ./ausrollen.sh alles | vorschau <name> | stand | zurück | unterbau. Die Nummer wird selbst gefunden. VOR jedem Ausrollen laufen zwingend: Formate laden, caption_check.py, caption_vorlage.py, npm run build UND der Selbsttest im echten Browser (headless Chromium, --dump-dom, Suche nach "Alles in Ordnung"). Letzterer ist der wichtigste: ein Fehler in EINER ui.jsx reisst die ganze Seite mit, und "npm run build" merkt das NICHT — der Fehler entsteht erst beim Aufbauen im Browser. Bei mehreren parallel arbeitenden Sessions ist das die einzige Prüfung, die fremde kaputte Arbeit vor dem Ausrollen abfaengt. "vorschau <name>" schaltet einen Stand als getaggte Cloud-Run-Fassung OHNE Verkehr frei — eigene Adresse, gleiches Passwort, Merts Adresse unberuehrt. Damit muss eine Format-Session nicht mehr auf die Reelforge-Session warten, um in der Cloud zu testen.
Kein eigener Git-Zweig je Session — alle teilen sich EINEN Arbeitsordner
Festgehalten 2026-07-30, nachdem genau das als Verbesserung vorgeschlagen wurde und sich beim Nachsehen als schaedlich herausstellte. Ein Git-Zweig hängt am ARBEITSORDNER, nicht an der Session — und alle Sessions arbeiten in /home/pi/reelforge. Ein "git checkout" würde allen anderen mitten in der Arbeit die Dateien austauschen. Alle bleiben auf main. Dass halbfertige Arbeit Mert nicht erreicht, sichern stattdessen drei Dinge: available=False (die Reel-Art taucht in seiner Oberflaeche gar nicht auf), Vorschau-Adressen (Testen ohne Ausrollen) und der Selbsttest als Tuersteher vor dem Ausrollen. Echte Zweige würden pro Session einen eigenen Ordner brauchen (git worktree) — Umbau von tmux-Sessions, Pfaden und Syncthing, nicht nebenbei zu machen.
Schluessel gehoerten nie ins Render-Abbild — .env war mit eingebacken
Gefunden und behoben 2026-07-30 beim Sicherheits-Check vor der GitHub-Sicherung. Die .dockerignore schloss die .env NICHT aus, also hat "COPY . /app" den ElevenLabs-Schluessel in jedes Render-Abbild gebacken (bis einschliesslich render:v14). Benutzt hat ihn dort nie etwas — formate/vox/stimme.py sucht die Datei unter dem festen Pi-Pfad, den es im Container gar nicht gibt. Die Abbilder liegen in einer privaten Artifact Registry, das Risiko war also klein, aber es gehört nicht dorthin. Ab jetzt in .dockerignore ausgeschlossen (zusammen mit .git, .claude und den Entwicklungswerkzeugen). In der Cloud kommen Schluessel aus dem Google-Tresor. Ob der Schluessel getauscht wird, entscheidet Mert.
Caption-Auswahl: ein Vorschaubild und zwei Schalter statt vier Kacheln
Umgebaut 2026-07-29 auf Merts Rueckmeldung ("die Bildvorlage ist noch nicht gut genug"). Nach dem Ausduennen zeigte die Auswahl drei fast identische Kacheln — die Varianten unterscheiden sich nur in Bewegung und Farbe, und Bewegung sieht man im Standbild GAR NICHT. Jetzt: EIN grosses Vorschaubild plus zwei Umschalter (Bewegung: Schub/Ohne · Schreibschrift: Weiss/Sandgelb). Das Bild hängt nur an der Farbe; beim Bewegungs-Schalter steht "im Standbild nicht zu sehen" dabei, statt ein Bild vorzutaeuschen, das nichts zeigt. Damit beide Schalter jede Stellung können, ist die vierte Kombination nachgetragen (held-erscheinen-warm) — ein Schalter mit einer toten Stellung ist kaputt. Welche Eigenschaften als Schalter erscheinen, sagt der Server (caption_bridge.SCHALTER), damit Beschriftung und Verhalten nicht auseinanderlaufen. ZWEITER FEHLER dabei gefunden: das Vorschaubild wurde in der Oberflaeche auf 420x244 beschnitten (object-fit: cover), abgeschnitten wurde ausgerechnet das grosse Schreibschrift-Wort — also genau das, was den Look ausmacht. Den Ausschnitt bestimmt jetzt allein make_caption_previews.py; die Bilder sind doppelt so gross (840 px, scharf auf dem Handy), zeigen sechs Woerter statt vier (damit die Treppe überhaupt sichtbar ist) und haben Vignette plus feines Korn, damit die Kachel nach Videobild aussieht und nicht nach Textfeld.
Nur noch ein Caption-Look: Held. Die anderen vier sind gelöscht
Entschieden 2026-07-29 von Mert ("loesch alle Caption-Stile bis auf den letzten"). Von 14 Eintraegen bleiben 3: Held — Schub, Erscheinen, warm. Gelöscht sind der alte Karaoke-Eintrag "klassisch", Collage, Wort für Wort (3), Mittelweg (3) und Schlicht (3) — und zwar RICHTIG gelöscht, nicht nur aus der Auswahl genommen: caption_engine.py schrumpft von 1722 auf 700 Zeilen (Bewegungskatalog, Rollen, Kaestchen-Anordnung, sechs Kompositionen, drei Stil-Sätze raus), caption_bridge.baue_untertitel hat nur noch einen Zweig, die elf Vorschaubilder unter static/captions sind weg. GRUND fuers echte Löschen statt Ausblenden: unerreichbarer Code ist in genau diesem Projekt schon dreimal die Brutstaette des stillen Rueckfalls gewesen — was niemand mehr auswaehlen kann, prüft auch niemand mehr. RUECKWAERTS: alte Auftraege und alte Browser-Staende tragen die gestrichenen Namen noch. caption_bridge.gueltiger_stil() biegt sie auf held-schub um und SCHREIBT DAS INS RENDERLOG (kein stiller Tausch); die Oberflaeche raeumt einen gespeicherten Stand beim Start auf. Der alte Karaoke-Renderer selbst bleibt im Code und ist über captionStyle="klassisch" weiter erreichbar, nur nicht mehr anklickbar. Wer die geloeschten Stile sucht: Commit ab25ad2 und früher.
Caption-Gruppen folgen Zeilen, nicht der Wortzahl
Behoben 2026-07-29 auf Merts Rueckmeldung (Screenshot: im Bild stand "gon do. Sag mir nicht, dass alles okay" — Ende der einen und Anfang der nächsten Zeile in EINER Gruppe). Ursache: die Gruppierung schnitt stur nach `max_woerter` ab, der Rest einer langen Zeile klebte an der nächsten. Jetzt zwei Durchgaenge: (1) HARTE GRENZEN — Satzende im Songtext oder Gesangspause; hier endet eine Gruppe immer, egal wie kurz sie dadurch wird. (2) Zu lange Gruppen werden an ihrer BESTEN inneren Grenze geteilt (größte Luecke, Satzzeichen-Bonus, Mitte bevorzugt) statt abgeschnitten — aus zehn Woertern werden zweimal fünf, nicht acht plus zwei. Die Pausenschwelle ist nicht mehr fest, sondern wird je Song aus den gemessenen Luecken abgeleitet (Median mal 3 plus 0,12 s, begrenzt auf 0,28 bis 0,55 s) — eine Ballade hat andere Pausen als ein Rap, ein fester Wert passt bei einem von beiden nie. Satzzeichen sind dabei das verlaesslichste Signal, weil sie aus dem getippten Text kommen und nicht aus einer Messung. Neue Dauerpruefung in caption_check.py: keine Gruppe darf über ein Satzende oder eine deutliche Pause hinweglaufen.
Captions: jedes Wort auf seiner eigenen Zeit — und Abschnittsmarken raus
Behoben 2026-07-29 auf Merts Rueckmeldung ("das erste Wort passt, danach kommen ein paar Woerter im Block"). ZWEI Fehler. (1) TIMING: Der Held-Stil setzte ALLE Woerter einer Gruppe auf den Zeitpunkt des ersten Wortes und liess sie nur mit einem festen Versatz von 70 ms je Zeile einlaufen — die auf 90 ms genaue Wortzuordnung war damit wertlos. Dieselbe Sorte Fehler in der Collage (90 ms Aufschlag JE WORT, beim vierten Wort fast eine halbe Sekunde zu spaet) und im Mittelweg (fester Versatz von 0,12 s statt der echten Zeit des Kernworts). Jetzt bekommt jedes Wort seinen eigenen Einsatz aus der Zuordnung. Neue Dauerpruefung in caption_check.py: JEDER Einsatz im fertigen ASS muss auf dem Einsatz eines echten Wortes liegen (60 ms Toleranz) — damit kann sich kein kuenstlicher Versatz mehr einschleichen. (2) ABSCHNITTSMARKEN: "[Hook]", "Verse 2:", "(Chorus)" standen im Video. Sie gingen ungefiltert in die Wortzuordnung — die hat sie im Gesang gesucht, nicht gefunden und dadurch auch die Zeiten der echten Woerter drumherum verzogen. caption_timing.ohne_abschnittsmarken() wirft sie jetzt aus dem Songtext, bevor zugeordnet wird; caption_bridge filtert geklammerte Marken zusätzlich heraus. Bewusst vorsichtig: ein blankes "Bridge" oder "Drop" bleibt stehen, weil es eine echte Songzeile sein kann — gestrichen wird nur, was geklammert ist oder allein auf einer Zeile steht.
Held-Captions bilden Merts Vorlage jetzt nach — messbar, nicht nach Gefuehl
Entschieden 2026-07-29, zweiter Durchgang auf Merts Ansage "so lange arbeiten, bis das Gerenderte exakt wie der Screenshot aussieht". Neues Werkzeug caption_vorlage.py: Die Vorlage (uploads/paste_1785338174295.png) ist Zeile für Zeile ausgemessen; das eigene Ergebnis wird gerendert, ebenfalls vermessen und BEIDES auf denselben Block normiert (Anteile der Blockbreite statt Pixel — die Vorlage ist ein 262x184-Ausschnitt, wir rendern 1080x1920). Verglichen werden Zeilenaufteilung, linke und rechte Kante, Grundlinienabstand und Groessenverhaeltnis. Ausgangswert 21,6 Prozent mittlere Abweichung, jetzt 1,0 Prozent (größte Einzelabweichung 3,5 Prozent). VIER Regeln machen den Unterschied, alle an der Vorlage gemessen: (1) Schriftwechsel je WORT statt je Zeile — Schreibschrift bekommen genau das erste Wort der Gruppe und das Heldenwort, alles andere ist fette Grotesk, auch mitten in derselben Zeile ("And" in Schreibschrift, "if you just do" direkt daneben). (2) Der Groessensprung ist KLEIN: das Heldenwort hat nur die 1,5-fache x-Hoehe, nicht die 2,6-fache wie im ersten Anlauf. Gross wirkt es trotzdem, weil die Schreibschrift lange Ober- und Unterlaengen hat. (3) Die Zeilen ziehen sich nach links ein (erste Zeile volle Blockbreite, jede weitere 10,5 Prozent weiter). (4) Zeilenabstand 1,7 x-Hoehen der neuen Zeile. Block fuellt 78 Prozent der Bildbreite. Woerter je Gruppe von 6 auf 8, weil die Vorlage acht hat.
Schreibschrift Great Vibes ersetzt durch Niconne
Entschieden 2026-07-29. Great Vibes ist NICHT die Schrift aus Merts Vorlage: das Wort "three" hat dort ein Seitenverhaeltnis von 2,45, in Great Vibes 1,56 — sie ist also deutlich schmaler und feiner. Ausgewaehlt wurde aus 14 Schreibschriften von Google Fonts, erst per Formvergleich gegen die Vorlage (Masken uebereinandergelegt), dann per Sichtvergleich des KOMPLETTEN Satzes gerendert. Niconne trifft die Proportionen am besten (2,39 gegen 2,45) und die Form des Schwung-A in "And". Die exakte Schrift der Vorlage ist vermutlich eine CapCut-Hausschrift und nicht frei zu haben. Great Vibes bleibt im Ordner (andere Modi), Niconne ist in Dockerfile.render mit angemeldet und wird dort beim Bauen geprüft. Außerdem: Zahlwoerter bekommen bei der Wahl des Heldenworts einen Zuschlag — in Erklaer-Reels ist die Zahl der Haken ("these THREE things"). Ohne den Zuschlag waere "things" gross gesetzt worden.
Ausgerollt: Oberflaeche ui:v21, Render render:v12 (Gruppen an Zeilengrenzen)
Ausgerollt 2026-07-29. Im ausgerollten Abbild gegengeprueft: Merts Beispielzeile ("like i dont know what this whole pain gon do." + nächste Zeile) wird dort in "like i dont know what" / "this whole pain gon do." / "Sag mir nicht dass alles okay" geteilt — kein Ueberlaufen mehr in die nächste Zeile.
Ausgerollt: Oberflaeche ui:v20, Render render:v11 (Wort-Timing, Marken-Filter)
Ausgerollt 2026-07-29. Im ausgerollten Abbild gegengeprueft (Cloud Build, amd64): Marken-Filter macht aus "[Hook] / Du fehlst mir" ein sauberes "Du fehlst mir", die Timing-Prüfung meldet ok, Pruefstand ohne Beanstandung.
Ausgerollt: Oberflaeche ui:v19, Render render:v10 (Vorlagen-Setzung)
Ausgerollt 2026-07-29. Enthaelt die Held-Setzung nach Merts Vorlage und die Schreibschrift Niconne. Gegengeprueft IM ausgerollten Render-Abbild (Cloud Build, amd64): Vorlagen-Abgleich 1,2 Prozent mittlere Abweichung (auf dem Pi 1,0 — der Unterschied kommt von der Schrift-Rasterung, nicht vom Layout), Pruefstand ohne Beanstandung. Der Schriften-Test in Dockerfile.render bricht ab, falls Niconne im Abbild fehlt — der Bau lief durch, also ist sie da.
Ausgerollt: Oberflaeche ui:v18, Render render:v9 (Captions)
Ausgerollt 2026-07-29. Enthaelt die komplette Caption-Ueberarbeitung (Umrechnung der Schriftgroessen, Zeilensatz im Held-Stil, x-Hoehen statt Punktzahlen, drei behobene Zeitueberlappungen) sowie den bis dahin committeten Vox-Stand (bleibt gesperrt, available=False). Gegengeprueft NICHT nur durch "gebaut, also gut": der Pruefstand caption_check.py lief per Cloud Build IM ausgerollten Render-Abbild auf amd64 — Vorhersage und libass-Ergebnis stimmen dort genauso, keine Beanstandung. Die Vorschaubilder im Oberflaechen-Abbild wurden über ihre Pruefsumme gegen die lokalen Dateien verglichen (identisch).
Captions: libass misst Schriftgroessen anders als das Messwerkzeug — 24 bis 44 Prozent
Gefunden 2026-07-29 (Sitzung Reelforge, Auftrag Mert "Captions müssen perfekt werden"). Die Caption-Engine misst Woerter mit PIL und lässt libass malen. Beide meinen mit "Schriftgroesse 100" etwas ANDERES: PIL das Geviert der Schrift, libass die Summe aus Ober- und Unterlaenge der OS/2-Tabelle (VSFilter-Erbe). Bei DM Sans sind das 1,32 Geviert, bei Great Vibes 1,75 — dieselbe Zahl ergibt also in Schreibschrift eine 24 Prozent kleinere Schrift als in der Grotesk. Folge: JEDE Messung dieser Engine war je nach Schrift 24 bis 44 Prozent zu gross, und beim MISCHEN zweier Schriften stimmte das Groessenverhaeltnis um ein Drittel nicht — genau der Effekt ("der grosse Held sieht aus wie die kleinen Woerter"), gegen den hier zuvor mit Faustkorrekturen angebaut wurde. Behoben mit _ass_skala() in caption_engine.py: Geviert geteilt durch (usWinAscent + usWinDescent), direkt aus der Schriftdatei gelesen, alle Messungen laufen dadurch. Gegenprobe im Pruefstand: Vorhersage und gerendertes Bild stimmen jetzt auf 1 bis 3 Prozent. Merksatz für alle Sitzungen: Punktgroessen sind NICHT vergleichbar — weder zwischen zwei Schriften noch zwischen PIL und libass. Immer über die x-Hoehe rechnen.
Caption-Pruefstand: Bilder rendern und nachmessen statt hinschauen und hoffen
Eingefuehrt 2026-07-29 mit caption_check.py. Bis dahin konnte niemand sagen, ob eine Caption wirklich sitzt. Der Pruefstand rendert jeden Stil mit der ECHTEN Kette (ffmpeg + libass, dieselben Schriften) auf drei Hintergruende — dunkel, hell, unruhig — und misst das Ergebnis: sicherer Bereich, Beschnitt, Lage im Bild, Zeilenhoehen, Kontrast (getrennt nach Fuellung und Kontur), und — der Test, der die meisten Fehler gefunden hat — ob sich zwei Woerter UEBERDRUCKEN. Letzteres auf Buchstabenebene: jedes Wort wird als Tintenbild gerendert und mit den anderen verschnitten. Mit Kaesten geht das nicht, weil der Kasten einer Schreibschrift zu drei Vierteln aus Luft besteht. Gemessen wird gegen den nackten Hintergrund (Bilddifferenz = exakt die Schrift). Dazu ein Kontaktbogen zum Draufschauen. Abbruchcode 1 bei jeder Beanstandung. Aufruf: python3 caption_check.py [stil-id ...] --satz kurz --grund hell
Held-Captions neu gesetzt: Zeilenblock statt Wortwolke
Entschieden 2026-07-29 nach Mert-Vorlage (Standbild aus fremdem Reel). Die alte Setzung stapelte kleine Woerter an die Flanken des grossen Schreibschrift-Worts; ab vier Woertern wurde daraus unlesbarer Matsch (im Pruefbild belegt). Jetzt: Zeilen in Lesereihenfolge, Schreibschrift und fette Grotesk im WECHSEL Zeile für Zeile (ausgehend von der Heldenzeile), Zeilen versetzt, und die Verzahnung wird gerechnet statt geraten — die Zeilen werden so eng geschoben, wie ihre Buchstabenbilder es zulassen. Dazu eine Blockfuellung: die ganze Gruppe wird skaliert, bis sie das Bild ausfuellt, damit das Schriftgewicht über alle Zeilen eines Videos gleich bleibt. Woerter je Gruppe von 4 auf 6 erhöht. Findet die Verzahnung keinen Platz, gibt es einen LAUTEN Notausgang (VERZAHNUNG_NOTAUSGANG) statt stillem Stehenbleiben.
Alle Caption-Groessen laufen über die x-Hoehe, nicht über Punktzahlen
Umgestellt 2026-07-29. Vorher standen in jedem Stil feste Punktzahlen (66, 108, 158), die auf dem Bildschirm gefuehlt gewählt waren. Wegen der libass-Umrechnung kamen daraus rund halb so grosse Captions wie gedacht — im Pruefbild deutlich zu klein für ein Reel. Jetzt gibt jeder Stil eine ZIEL-x-HOEHE als Anteil der Bildbreite an (schlicht 5,2 %, Wort-für-Wort 5,4 / 6,8 %, Mittelweg 8,0 / 3,2 %, Collage 10,5 bis 4,2 %); die Punktzahl rechnet die Engine je Schrift aus. Damit sind die Stile untereinander vergleichbar und schriftunabhaengig.
Caption-Gruppen duerfen sich zeitlich nicht mehr ueberlappen
Behoben 2026-07-29, drei getrennte Stellen mit demselben Muster: (1) _ende() im caption_bridge hob seinen eigenen Deckel wieder auf (max(ende, letztes_wort + 0,05)), (2) die Collage liess jedes Wort noch Einblendzeit plus 500 ms Haltezeit über das Gruppenende hinaus stehen, (3) Wort-für-Wort liess die Gruppe in derselben Sekunde verschwinden, in der das letzte Wort verklingt — die fertige Zeile war nur einen Wimpernschlag zu sehen. Ergebnis war jeweils dasselbe: zwei Gruppen gleichzeitig im Bild, die sich gegenseitig ueberdrucken. Im Pruefstand als Kollision aufgefallen.
Reels über 32 MB waren unabspielbar — und der Fehler wuchs mit der Laenge herein2026-07-31
Gefunden 2026-07-31, gemeldet von Mert ("laedt kurz, danach passiert nichts, aber ich sehe es in der Auswahl"). Nachgestellt mit curl (anmelden, dann "Range: bytes=0-" wie ein Browser): HTTP 500. Im Cloud-Protokoll im Klartext: "Response size was too large." URSACHE: Ein Player fragt als erstes die GANZE Datei an. cloud_server:_liefere_blob hat das woertlich genommen und 43,7 MB in einer Antwort geschickt; Cloud Run bricht Antworten dieser Größe mit 500 ab. WARUM ES NIEMAND GEMERKT HAT: Das Petrow-Reel ist 27,7 MB und lag knapp UNTER der Grenze, das Radium-Reel mit 49,6 s hat 43,7 MB. Der Fehler ist also mit der Reel-Laenge hereingewachsen — die Liste sah normal aus, Vorschaubild inklusive. BEHOBEN: Antworten auf 8 MB gedeckelt (eine kuerzere Antwort als angefragt ist bei Bereichsabfragen erlaubt, der Player holt den Rest). Beim Herunterladen ohne Range entfaellt bei grossen Dateien das Content-Length — nur ohne Content-Length liefert Flask haeppchenweise, und nur haeppchenweise gilt die Grenze nicht. Dieselbe Deckelung für die Tonspur. Belegt nach dem Ausrollen: 206 statt 500, 8 MB je Stück, erstes Byte nach 1,7 s, Springen mitten im Video liefert den richtigen Bereich. AUSGEROLLT ALS ui:v28 OHNE die Caption-Pruefungen — bewusst und einmalig: die laufen seit heute in der Cloud, eine andere Session hatte gleichzeitig einen Prueflauf am Laufen, und meiner stand nach 12 Minuten noch in der Warteschlange, während Mert sein Video nicht ansehen konnte. Die Caption-Pruefungen bewachen das RENDER-Abbild; der UI-Container enthaelt weder ffmpeg noch die Caption-Engine, die Änderung liegt allein in cloud_server.py. Geprüft wurde stattdessen direkt das Ergebnis (siehe oben). Das Render-Abbild blieb unangetastet auf v18.
Vox ist freigeschaltet — und wird per Skill gebaut, nicht im Browser2026-07-31
Ausgerollt 2026-07-31 als ui:v29 und render:v20, aus dem abgelegten Stand. Nachgelesen statt geglaubt: /api/formats meldet "Vox Explainer" als verfügbar, eine Bereichsabfrage auf das Radium-Reel liefert 206 mit 8-MB-Stück. available steht auf True, nachdem Mert das Radium-Reel abgenommen hat ("sieht extrem gut aus"). Die Bedingung stand seit dem Bau: EIN echtes Reel, keine Testbilder. WEG ZUM REEL — bewusste Entscheidung von Mert: nicht über den Browser, sondern über die Session. "Lass es hier auf dem Pi, so dass ich dir einfach nur sage: erstelle ein Vox-Video." Dafür gibt es den Skill vox-reel (formate/vox/SKILL.md, per Symlink in .agents/skills eingehaengt). Er buendelt, was heute einzeln teuer gelernt wurde: die sechs Skript-Regeln, den Drehbuch-Vertrag, die Kostenregel und die Lehre "animiert wird nur, wo sich physikalisch etwas bewegen KANN". WARUM DIE DATEI IN formate/vox/ LIEGT: .agents/ und .claude/skills/ sind von Git ausgenommen — dort waere der Skill nur auf der SD-Karte gelandet, also genau die Sicherungsluecke, wegen der das Repo überhaupt existiert. In der Oberflaeche sieht Mert die fertigen Reels, kann sie abspielen und herunterladen. Bauen läuft über die Session; der Klickweg dafür ist zurueckgestellt, nicht vergessen.
Merts vier Punkte zum ersten Vox-Reel — zwei sofort im Bild, zwei brauchen Credits2026-07-31
Rueckmeldung 2026-07-31 nach dem ersten fertigen Reel. Umgesetzt in render:v18. (1) KAMERAFAHRTEN "zu oft Zoom". Belegt: bei Hochformat standen drei von vier Fahrten still oder zoomten, und Vox hat fast nur 9:16-Bilder. Jetzt vier Schwenks auf zwei Zooms in beide Richtungen. Am Petrow-Reel nachgezaehlt: 6 Schwenks zu 2 Zooms auf 8 Standbildern (vorher umgekehrt). "ruhig" ist raus — ein sehr langsamer Zoom, der neben echten Fahrten wie ein vergessenes Standbild aussieht; Videoclips behalten ihn, die bringen ihre Bewegung selbst mit. (2) ROTES SCHLUESSELWORT. *wort* im Skript wird im Textstempel rot gesetzt, auch mehrere Woerter am Stück; Zahlen weiterhin automatisch. VON HAND, weil kein Programm zuverlaessig raet, welches Wort den Satz traegt ("Er meldet NICHT" vs "FÜNF Raketen") — ein falsch geratenes rotes Wort fuehrt das Auge an die falsche Stelle. Die Sternchen gehen NUR ins Bild: stimme.py und die Wortzuordnung bekommen den Text ohne sie (sonst spricht ElevenLabs sie mit), die Wortanzahl bleibt gleich, Zeilen und Zeiten also parallel. Nur Farbe, keine Größe: der Zeilenumbruch ist auf die Stempelgroesse gerechnet. (3) "WIRKT ZU SEHR KI". Was ein Bild verraet, ist die Fehlerlosigkeit — also werden die Fehler jetzt bestellt: Passerfehler im roten Druck, ungerade Scherenschnitte, Staub, Fingerabdruecke, welliges Papier, grobe 60er-Halbtonraster, Motiv ausdruecklich aussermittig. "ultra-detailed, 8K" ist RAUS (zieht jedes Modell Richtung Hochglanz); stattdessen wird das Medium beschrieben. NACHTRAG 2026-08-01, KORRIGIERT: hier stand "NICHT GEMESSEN — kostet einen Testlauf mit Credits". Das ist ueberholt. Die Ueberarbeitung liegt seit af82eeb (31.07. 08:42) im Code, die Bilder von Radium (09:55) und Phantom (13:55) sind danach entstanden — sie sind also bereits damit erzeugt, und Mert hat das Radium-Reel danach abgenommen ("sieht extrem gut aus"). Ein eigener Testlauf eruebrigt sich. Wer am Stilblock zweifelt, schaut die zwei Reels an, statt Credits auszugeben. (4) "ZU WENIG SPANNUNG". Der Einsatz gehört in den ersten Satz, nicht in Sekunde 20; die Ortsmarke rutscht auf Zeile 2. Drei Formeln in SKRIPT.md und im Chat-Prompt. skript.py prüft es — erste Fassung war zu nachsichtig (nahm jede Zahl, also auch "1983", und liess damit genau die Zeile durch, wegen der Mert sich gemeldet hat); Jahreszahlen zählen jetzt nicht mehr. Wirkt erst mit einem NEUEN Skript: eine neue Hakenzeile ist eine neue Szene und damit ein neues Bild. ZU "nicht immer zu 100% wahrheitsgemaess" (Merts Wunsch): zugespitzt ja, erfundene Zahlen/Namen/Daten nein. Praktischer Grund, kein moralischer — die Kommentare korrigieren einen dokumentierten Fall binnen einer Stunde, und der Bau bricht ohnehin ab, weil ein Etikett nur Zahlen tragen darf, die im Skript stehen.
Ausgerollt: render:v17 und ui:v27 — das erste Vox-Reel liegt in Merts Galerie2026-07-31
Ausgerollt 2026-07-31 nach Merts Freigabe, aus dem abgelegten Stand c16450a bzw. 22cb31c. Pflichtpruefungen sauber (Vorlagen-Abweichung 1,0 % im Mittel, Grenze ~2 %). Verkehr folgt der neuesten Fassung, hängt also nicht an einer Vorschau fest. ANLASS render:v17 — ohne die rekursive Pfad-Umschreibung aus cloud_render.py brach jeder Vox-Schnitt mit Musik ab. ANLASS ui:v27 — /api/videos listete jedes .mp4 unter jobs/, also auch die hochgeladenen Zutaten in jobs/<id>/in/clips/. Bei Vox waren das vier Karteileichen je Reel, die beim Antippen ins Leere liefen (abgespielt wird über /api/video/<id>, und das sucht richtigerweise nur in out/). PRUEFREGEL DES PROJEKTS ERFUELLT: Nach jeder Änderung am Render-Abbild muss belegt sein, dass die gute Engine läuft und nicht still der Notfall-Renderer. Im Cloud-Protokoll des Laufs 461f9a39ac50 steht "Align: 100%". ERGEBNIS, gemessen statt behauptet: 37,8 s, 1080x1920, h264 + aac, Vorschaubild erzeugt. Musik belegt über silencedetect — im ganzen Reel KEINE Stelle unter -45 dB, während ElevenLabs in den Sprechpausen echte Stille (-85 dB) liefert. Ohne Musikbett müssten dort Luecken sein. Auftrag 73c382453e89 (derselbe Lauf ohne Musik, auf v16 entstanden) liegt noch als zweites Reel in der Galerie und kann dort gelöscht werden.
Vox rendert in der Cloud — der Pi schiebt nur noch Dateien2026-07-31
Gebaut 2026-07-31, nachdem das Rendern auf dem Pi gesperrt wurde. Nachgewiesen mit einem echten Lauf (Auftrag 73c382453e89, 12 Szenen, 14 Dateien): Ergebnis 37,8 s, 1080x1920, h264+aac — Bild für Bild dieselben Kennzahlen wie der Pi-Render davor. NEU: formate/vox/wolke.py (Vox-Revier). Laedt den Auftragsordner nach gs://…/jobs/<id>/in/, schreibt job.json mit "/in"-Pfaden, weckt den Cloud-Run-Job per gcloud (Kennung als Ausfuehrungs-Override, nicht dauerhaft gesetzt), sieht dem Fortschritt zu und holt das fertige REEL.mp4 zurück. Über die gcloud-Befehlszeile statt über google-cloud-storage: die Bibliothek ist auf dem Pi nicht installiert, und sie für ein Hochlade-Werkzeug nachzuziehen waere das Falsche. Es geht bewusst AN DER OBERFLAECHE VORBEI. Erstens kann die noch keinen Szenen-Ordner hochladen (siehe tasks), zweitens nimmt der Render-Job jedes geladene Format an, auch ein gesperrtes (available=False) — Vox lässt sich dadurch in der Cloud fertig prüfen, BEVOR es in Merts Oberflaeche auftaucht. DREI KERN-LUECKEN GESCHLOSSEN, die den Browser-Weg betrafen: (1) cloud_server.py kopierte nur Videodateien in den Auftrag — Vox besteht groesstenteils aus Standbildern. (2) Es kopierte immer die GANZE Clip-Bibliothek statt des gewaehlten Ordners; bei Vox reicht eine fremde Datei, und der Schnitt bricht mit "Anzahl passt nicht" ab. Welche der beiden Betriebsarten gilt, sagt jetzt das Format selbst über META["szenen"] — der Server müsste es sonst raten, und Bilder in einem Hintergrund-Clip-Ordner würden lyrics_std & Co. stoeren. (3) cloud_render.py:_fix_paths bog nur die OBERSTE Ebene der Job-Beschreibung um; Pfade in "settings" — bei Vox die Musik — blieben auf einem Ordner stehen, den es im Container nicht gibt. Jetzt rekursiv. Vox faellt dabei laut auf die Nase; ein Format, das fehlende Musik verzeiht, haette still ein stummes Reel geliefert. OFFEN: das Abbild render:v16 (2026-07-30) hat (3) noch nicht — bis zum nächsten "./ausrollen.sh render" läuft Vox nur mit --ohne-musik.
Auf dem Pi wird nicht mehr gerendert — die Sperre sitzt im Engpass, nicht im Format2026-07-31
Eingebaut 2026-07-31 auf Merts ausdrueckliche Ansage ("der Pi managt, gerendert wird woanders"). Anlass: Am 2026-07-30 um 23:07 hat ein Vox-Schnitt (über "python3 -m formate.vox.mach") den Pi HART NEUGESTARTET. Bedarf rund 2,4 GB (Sprachmodell für die Wortzeiten plus ffmpeg für 12 Szenen in 1080x1920), RAM und Swap voll, OOM-Killer raeumt wahllos ab, der systemd-Watchdog (1 Minute) setzt das Board zurück — ALLE tmux-Sessions und Dienste weg, nicht nur der eigene Vorgang. Der Lauf davor ging durch; genau das macht es gefaehrlich, ein Fehler der meistens nicht auftritt wird nicht behoben sondern geglaubt. WO DIE SPERRE SITZT: in formate.Auftrag.__init__ (formate/__init__.py:pruefe_rechner). Einen Auftrag baut nur, wer gleich rendert — damit greift die Regel bei JEDEM Format und auf JEDEM Weg: Oberflaeche (server.py), Befehlszeile (render_cli.py), Cloud (cloud_render.py, dort wirkungslos) und formatseigene Werkzeuge. Erst als Vox-eigene Prüfung gebaut, dann bewusst hochgezogen: acht Formate mit acht Kopien derselben Regel heißt, dass die neunte sie vergisst. Nichts Schweres läuft vor dem Auftrag, die Sperre greift also VOR jedem Rechenaufwand. ERKENNUNG über die Prozessor-Architektur (arm64 = Pi, Cloud Run = x86_64). Damit kann die Sperre den Produktivweg gar nicht blockieren — eine Schutzmassnahme, die den Normalbetrieb stoert, wird beim ersten Zwischenfall wieder ausgebaut. mach.py prüft zusätzlich VOR der Bilderbestellung, damit nicht erst Credits ausgegeben werden und dann der letzte Schritt streikt. Notausgang nach Absprache: REELFORGE_RENDERN_AUF_DEM_PI=ja, mit Warnung im Protokoll. NICHT betroffen: caption_check.py und caption_vorlage.py (Pflichtpruefungen vor jedem Ausrollen). Die zeichnen einzelne Standbilder statt Videos, bauen keinen Auftrag und laufen weiter — sonst waere das Ausrollen mitgesperrt. FOLGE: Für Vox gibt es damit derzeit KEINEN regulaeren Weg zum fertigen Reel — der Cloud-Weg hat drei Luecken (siehe tasks). Bewusst so: lieber sichtbar blockiert als unsichtbar das Board riskieren. Die allgemeine Regel "auf der Pi-Hardware wird nichts gerendert" steht seit dem Vorfall in der globalen /home/pi/.claude/CLAUDE.md und gilt für alle Projekte.
Neue Reel-Art Vox Explainer: ein CUTTER, kein Zeichenprogramm
Entschieden 2026-07-29 mit Mert (Sitzung RF-Vox, vorher NeueIdee). Vorlage ist der Ablauf aus youtube RaxX_Q7Apj0. Erster Irrweg: die Vox-Optik (Papier, Filzstift, Kamerawackeln) in Python nachbauen. FALSCH — im Vorbild entsteht die Optik in den BILD-Werkzeugen, die Bewegung kommt aus einem Videomodell. Der einzige Handgriff, der dort übrig bleibt, ist eine halbe Stunde CapCut: Clips an den Sprecher schieben. GENAU DAS uebernimmt ReelForge jetzt, weil es die Sprecherspur auf ~90 ms genau mitliest (caption_timing) und jeden Clip von allein auf seinen Satz legt. Vertrag bewusst stumpf: eine Skriptzeile = eine Szene = eine Datei, alphabetisch sortiert. Jede kluegere Zuordnung könnte still danebengreifen; passt die Anzahl nicht, bricht der Schnitt ab. KOSTENHEBEL: Standbilder bekommen eine ffmpeg-Kamerafahrt statt KI-Bewegung. Bewegung ist ~77 Prozent der Kosten einer Reel-Kette; mit einem Drittel bewegter Szenen faellt ein Reel von ~975 auf ~325 OpenArt-Credits (10 statt 30 Reels aus 10.000). Gemessen am 2026-07-29: Sprecher 282 Zeichen = 20,1 s; Zuordnung 48 Woerter in 12 s; Schnitt von 7 Szenen in 72 s auf dem Pi. Sprache: ElevenLabs Gratis (10.000 Zeichen/Monat = ~16 Reels), Werkzeug formate/vox/stimme.py. demucs wird hier NICHT benutzt (trennen=False) — eine Sprecheraufnahme hat kein Instrumental zu trennen, das spart das Vierfache an Rechenzeit.
Fehler gefunden: amix hat die Sprecherstimme 6 dB leiser gemacht
Gemessen 2026-07-29 beim Bau von Vox. ffmpegs amix teilt ohne "normalize=0" jede Spur durch die Anzahl der Spuren — der Sprecher kam dadurch 6 dB leiser raus als das Original (-39,5 dB wurden zu -44,5 dB), während die Musik kaum hoerbar war. Ohne Nachmessen faellt so etwas NICHT auf: man dreht unbewusst lauter und wundert sich über schlechten Klang. Behoben mit normalize=0 plus alimiter. Merksatz für andere Formate, die Musik untermischen: nach dem Abmischen den Pegel gegen das Original messen, nicht nur hinhoeren.
Ausgerollt: ui:v17 und render:v8 — und /healthz war in der Cloud nie erreichbar2026-07-29
Ausgerollt am 2026-07-29 nach Merts Freigabe. Anlass: Der Pi-Hub verlinkt auf die CLOUD-Adresse, nicht auf den Pi — dort lief noch der Stand vom 28.07. 21:16. Zwei Welten nebeneinander (neue Vorschau auf dem Pi, alte App in der Cloud) haben mehrfach für Verwirrung gesorgt. Oberflaeche ui:v17 (Bau 1:21, mit Node-Stufe für das Vite-Bauergebnis), Render render:v8 (Bau 8:06). Die vorherigen Fassungen bleiben als Rueckfallebene stehen. PRUEFREGEL DES PROJEKTS ERFUELLT: Nach jeder Änderung am Render-Abbild muss belegt sein, dass die gute Engine läuft und nicht still der Notfall-Renderer. Prueflauf in der Cloud mit 10-Sekunden-Testton: "Align: 100%" im Log, gueltiges MP4 (1080x1920, h264 + aac, 10,0 s), Vorschaubild erzeugt, 22,9 Sekunden. Prueflauf danach wieder aus dem Zwischenspeicher entfernt. NEBENBEFUND: Der Gesundheits-Weg /healthz ist in der Cloud NIE erreichbar gewesen — Google faengt genau diese Adresse an seinem Eingang ab, die Anfrage kommt gar nicht beim Container an (belegt: /gibtsnicht123 liefert die 404-Seite der App, /healthz die von Google). Praktisch harmlos, weil ihn nichts benutzt, aber wieder dasselbe Muster wie bei der erfundenen Wellenform: eingebaut, sieht nach Absicherung aus, tut nichts. Beim nächsten Ausrollen auf einen Pfad umziehen, den Google durchlaesst.
Ordner kann jetzt suchen, sortieren und löschen — und der lokale Server konnte ihn gar nicht2026-07-29
Umgesetzt 2026-07-29. Suche nach Namen, vier Sortierungen, Löschen mit Rueckfrage. Suche und Sortierung stehen in der Adresse, ein Filter lässt sich also verlinken. DER EIGENTLICHE FUND kam vorher: Der LOKALE Server hatte die Ordner-Wege überhaupt nicht — /api/videos, /api/video, /api/download, /api/thumb, /api/clips gab es nur im Cloud-Server. In der Vorschau auf dem Pi war der Ordner deshalb IMMER leer, egal wie viel gerendert wurde. Jetzt verhalten sich beide Server gleich; ohne das haette ich Suche und Sortierung blind gegen die Cloud gebaut. ENTSCHEIDUNGEN: Suche und Sortierung erscheinen erst ab vier Eintraegen (bei drei Reels waeren sie nur Beiwerk, das den Blick aufhaelt). Die Rueckfrage vorm Löschen nennt den NAMEN — "Wirklich löschen?" allein sagt nicht was gelöscht wird, und genau daran gehen Dateien verloren. In der Cloud wird der ganze Auftragsordner gelöscht, nicht nur das Video: sonst bleiben Vorschaubild, Statusdatei und der Song liegen und der Speicher wächst still weiter — bezahlt wird nach Platz. ZWEI FEHLER BEIM BAUEN, beide lehrreich: (1) Beim Aufraeumen des toten Format-Rasters waren zwei Hilfsfunktionen für die Kachel-Beschriftung mitgeloescht worden, weil sie direkt danebenstanden. Aufgefallen ist es erst, als der Ordner zum ersten Mal ECHTE Videos enthielt — MERKSATZ: ein leerer Zustand testet die Liste nicht. (2) Die per Adresse mitgegebene Suche wurde sofort wieder gelöscht, weil der Effekt "Suche beim Regalwechsel zurücksetzen" auch beim ERSTEN Aufbau feuert. Der Link sah aus als funktioniere er, zeigte aber immer alles. GEPRÜFT: Suche filtert nachweislich (2 von 6 bei "spotify"), alle vier Sortierungen stimmen, Löschen entfernt die Datei wirklich, und vier Ausbruchsversuche mit ../-Pfaden prallen alle mit 404 ab.
Wellenform war erfunden — und ein Song liess sich auf dem Pi gar nicht abspielen2026-07-29
Kritische Durchsicht am 2026-07-29, vier Punkte behoben. DER WICHTIGSTE: Die Wellenform beim Song wurde aus dem DATEINAMEN gerechnet, nicht aus der Musik. Sie sah aus wie Daten, war aber ein Zufallsmuster — und man konnte sie anklicken, um zu springen. Eine Anzeige, die Daten behauptet und Rauschen zeigt, ist schlimmer als gar keine: man entscheidet danach ("da ist der Refrain") und liegt zwangslaeufig falsch. Jetzt misst der Browser die echte Datei (Web Audio) — bewusst im Browser, weil der Oberflaechen-Container absichtlich kein ffmpeg hat und klein bleiben soll. NACHGEWIESEN mit zwei Testtoenen: lauter werdend ergibt 0.12 … 1.00, leiser werdend 1.00 … 0.12; vorher haetten beide dasselbe Muster gezeigt. DABEI EIN ECHTER FEHLER GEFUNDEN: Songs liessen sich auf dem Pi gar nicht abspielen. /api/audio bekam einen absoluten Pfad, die Adresse enthielt dadurch einen doppelten Schraegstrich, Werkzeug leitete automatisch um und schluckte den fuehrenden Schraegstrich — danach war der Pfad relativ und die Datei nicht auffindbar. Warum es lange niemandem auffiel: auf Windows beginnt der Pfad mit "D:\\", also kein fuehrender Schraegstrich, also keine Umleitung. Der Fehler entstand erst mit dem Umzug auf Linux und betrifft nur den lokalen Server, nicht die Cloud (dort sind es Eimer-Namen ohne fuehrenden Schraegstrich). WEITER: Fehler kamen als Browser-Popup (7x alert) — blockiert alles, sieht nach Browser statt nach App aus, nach dem Wegklicken für immer weg; jetzt Meldungen in der App mit aria-live. Der Render-Knopf liess einen dagegenlaufen (Klick annehmen, dann Popup) — jetzt gesperrt mit "Es fehlt noch: Song fehlt". Und die Schrittnummern 1/2/3 brachen ab, seit die 4 auf die Startseite gewandert ist: ganz entfernt statt neu durchnummeriert, denn die Reihenfolge ist gar nicht zwingend — eine Nummer, die eine Reihenfolge verspricht die es nicht gibt, ist irrefuehrender als keine.
Startseite: die Auswahl der Reel-Art ist ein eigener Schritt2026-07-29
Umgesetzt 2026-07-29 auf Merts Wunsch. Die Auswahl steckte bisher in derselben Spalte wie die Einstellungen. Bei sieben Arten ging das gerade noch — bei fuenfzehn waere die Spalte eine Bleiwueste, durch die man sich scrollt, bevor man überhaupt an die Regler kommt. Und viele Arten sind genau das Ziel des Projekts. JETZT drei Abteile statt zwei: Start (Auswahl) · Reelmaker (Bauen) · Ordner (Ansehen). Start ist die Landeseite, mit "Weiter mit <letzter Art>" als Hauptknopf — sonst läuft, wer immer dieselbe Art baut, jedes Mal einen Umweg. Die Kacheln sind BILDGETRIEBEN und gross: ein Name wie "Story Scroll" sagt niemandem, wie das Ergebnis aussieht. Gruppiert in Verfügbar und Geplant, damit sichtbar bleibt, wohin die Reise geht. FOLGE für den Reelmaker: statt des grossen Kachelrasters nur noch eine schmale Zeile ("Reel-Art: X · Ändern"). Dadurch ist die mittlere Spalte frei — die Caption-Stile sind jetzt ohne Scrollen sichtbar. Das war nebenbei der größte Uebersichtlichkeits- gewinn des Umbaus. Die Liste kommt aus dem Register: eine neue Reel-Art erscheint von allein, ohne dass jemand hub.jsx anfasst — dieselbe Regel wie ueberall im Projekt. NEBENBEI: Spotify hatte als einziges Format kein Kachelbild und fiel auf der bildgetriebenen Seite sofort ab (nachgeliefert). Und FormatGrid/FormatThumb in panels.jsx sind damit tot und raus (65 Zeilen) — toter Code bleibt hier nicht liegen, die nächste Session haelt ihn sonst für lebendig.
Oberflaeche Phase 2 fertig — Design-System, Deko raus, eine Sprache2026-07-29
Umgesetzt 2026-07-29 nach Merts Vorgabe "dunkel bleibt, aber uebersichtlicher und professioneller". Als eigene Ebene web/src/theme.css ÜBER dem gewachsenen app.css — nicht als Neuschrift: app.css sind 344 Regeln, die das Layout tragen, alle auf einmal zu ersetzen waere ein Blindflug gewesen. VIER REGELN: Deko runter (kein Glas, kein Leuchten, keine Hintergrund-Verlaeufe — genau die drei lassen eine Oberflaeche nach Demo aussehen); Ordnung durch Helligkeit, Größe und Abstand statt durch Effekte; EINE Akzentfarbe an nur noch fünf Stellen; mehr Luft auf einem 4px-Raster. DER GRÖSSTE EINZELGEWINN war kein Farbwert: Die Format-Kacheln passen sich jetzt der Breite an, statt stur zweispaltig zu sein. Vorher schoben sieben grosse Kacheln die Einstellungen unter den Bildrand — man waehlte ein Format und musste erst scrollen, um es einstellen zu können. Das war der Hauptgrund für den unuebersichtlichen Eindruck. WEITER: Abspiel-Knopf neutral (vorher zwei gleich laute Cyan-Kreise uebereinander, die sich gegenseitig aufheben); echte leere Zustaende mit Symbol, Aussage und naechstem Schritt statt einer Zeile im Nichts; Sprache vereinheitlicht (die Oberflaeche mischte Deutsch und Englisch — "Drop an audio file", "Lyrics werden aligned"). ENTFERNT: die Laufzeit-Regler für Akzentfarbe/Schrift/Rundung/Dichte/Glas. Der Bedienkasten wurde ohnehin nirgends angezeigt, es lief nur die Nebenwirkung — beim Start wurden die Design-Werte ueberschrieben. Und ein Design, das fünf Akzentfarben und drei Dichten gleichzeitig gut aussehen lassen muss, sieht in keiner Kombination richtig gut aus. UMKEHRBAR: tweaks-panel.jsx liegt noch da. AUS DEN WEB INTERFACE GUIDELINES (Vercel, neu installiert): sichtbarer Tastatur-Fokus ueberall (gab es vorher gar nicht), prefers-reduced-motion, color-scheme und theme-color, touch-action gegen die Tipp-Verzoegerung, gleichlaufende Ziffern, Namen für alle Symbol-Knoepfe, und das offene Abteil steht jetzt in der Adresse (?abteil=ordner) — verlinkbar, und der Zurück-Knopf tut das Erwartete. STOLPERFALLE, die genau einmal zuschlug: app.css regelt das Handy-Layout in einem @media-Block. theme.css steht später in der Reihenfolge und hat diese Regeln ueberstimmt, obwohl gar nicht fuers Handy gedacht — Inhalt breiter als der Bildschirm. Deshalb hat theme.css am Ende einen eigenen Handy-Block. MERKSATZ: Wer eine bestehende Oberflaeche mit einer Ebene darüber umformt, muss deren Bildschirmgroessen-Regeln mitdenken. MESSFALLE beim Prüfen: Chromium erzwingt eine Mindest-Fensterbreite von 500px. Ein Bildschirmfoto mit --window-size=393 liefert eine 500px-Seite, zugeschnitten auf 393 — sieht aus wie ein kaputtes Layout, ist aber ein Messfehler. Kostete eine Runde. OFFEN: Grundbausteine auf shadcn/ui umstellen. Geruest steht (components.json, cn(), shadcn-MCP in .mcp.json) — sinnvoll beim nächsten groesseren Umbau eines Bausteins, nicht als Selbstzweck.
Oberflaeche Phase 1 fertig — gebaut statt im Browser uebersetzt2026-07-29
Umgesetzt 2026-07-29. Vite 7 + React 19 + TypeScript 5.9 + Tailwind 4 unter web/, Flask liefert das Bauergebnis aus (web_ausliefern.py), Dockerfile.ui baut die Oberflaeche in einer eigenen Stufe — Node landet NICHT im fertigen Abbild, nur das Ergebnis (326 MB). GEMESSEN: Auslieferung von ~3.235 KB auf 298 KB (gepackt 820 → 95 KB), und das Uebersetzen im Browser bei jedem Seitenaufruf faellt ganz weg. Der eigentliche Gewinn ist aber ein anderer: ab jetzt lassen sich npm-Pakete einbinden — vorher technisch unmöglich, und genau das war die Decke für eine Werkbank mit vielen Reel-Arten. BEWUSST NICHT ANGEFASST, damit Phase 1 beweisbar bleibt: Tailwind läuft ohne "preflight" (der Grundstil-Reset würde app.css sofort verschieben — kommt in Phase 2, wenn app.css ohnehin abgeloest wird), und die Bausteine reden weiter über window miteinander statt über import/export. Beides steht als Kommentar an Ort und Stelle. Bauweise umstellen UND alles auf Module umschreiben waeren zwei Risiken auf einmal gewesen; bei einem Fehler wuesste man nicht, welches davon schuld ist. FALLSTRICK, gleich mitgeloest: Die ui.jsx der Reel-Arten liegen absichtlich ausserhalb von web/ (ein Ordner je Reel-Art). Dort findet der Bauer React nicht, weil darüber kein node_modules liegt — geloest über feste Zuordnungen in vite.config.ts. DER SELBSTTEST ist in die App gewandert: /?selbsttest statt eigener HTML-Datei. Er prüft jetzt dieselben Bausteine, die auch die echte App benutzt — vorher einen Nachbau, was deutlich weniger wert war. GEPRÜFT: alle sieben Format-Kacheln plus Einstellungen, Vorschau und Kachelbild jedes aktiven Formats im echten Chromium; TypeScript sauber; Container lokal gebaut, gestartet und über die Anmeldung bis zur ausgelieferten Seite durchgetestet.
Oberflaeche Phase 0 entschieden: Vite + Tailwind v4 + shadcn/ui + TypeScript, dunkel bleibt2026-07-28
Mert am 2026-07-28, alle vier Grundsatzfragen beantwortet: (1) BAUKASTEN shadcn/ui + Tailwind v4 — ja. Bausteine werden ins Projekt kopiert und gehören uns, kein Rahmen zum Drin-Festsitzen. (2) BAUWERKZEUG Vite, nicht Next.js. ReelForge braucht keine Server-Seiten, Flask bleibt der Server — ein Cloud-Dienst weniger, der kaputtgehen kann. (3) TYPESCRIPT — ja. Bei vielen Formaten faengt es genau den Drift zwischen Kern und Format-Dateien ab, der sonst erst im Browser auffaellt. UMSETZUNG bewusst schrittweise: TypeScript wird eingerichtet, die bestehenden Dateien bleiben aber vorerst .jsx (allowJs). Alle acht Dateien gleichzeitig umzuschreiben waere Risiko ohne Gegenwert — Phase 1 soll die Bauweise beweisen, nicht den Code umwaelzen. (4) LOOK bleibt dunkel, aber "uebersichtlicher und professioneller" (Mert-Wortlaut). Uebersetzt in eine Arbeitsanweisung für Phase 2/3: Deko runter (Glow, Glas-Effekte, Farbspielereien im Tweaks-Panel), Hierarchie rauf (Größe, Gewicht und Abstand machen die Ordnung, nicht Effekte), mehr Luft, ruhigere Akzente. Der dunkle Grund bleibt — er lässt Bild und Video kraeftiger wirken, deshalb starten Kreativ-Werkzeuge fast alle dunkel. FOLGE für das Format-Register: Die ui.jsx-Dateien werden beim Bauen mit eingepackt (import.meta.glob) statt zur Laufzeit als Script geladen. Nur so kommen sie an die neuen Bausteine heran. Preis: eine neue Reel-Art braucht ein Ausrollen, bevor sie in der Web-App auftaucht — was für den Renderer ohnehin schon gilt.
Oberflaeche: Baukasten statt fertiger Vorlage — und warum die Bauweise vorher weg muss2026-07-28
Bestandsaufnahme 2026-07-28 auf Merts Wunsch, eine richtig professionelle Oberflaeche zu bauen. BEFUND: Es gibt keinen Build. React kommt vom CDN, JSX wird im Browser von Babel uebersetzt — bei jedem Seitenaufruf, rund 3 MB Uebersetzer vorweg. Babel selbst sagt, dass das nichts für den Produktivbetrieb ist. Die eigentliche Decke ist aber eine andere: ohne Build lässt sich KEIN npm-Paket einbinden, also kein shadcn/ui, keine fertigen Dialoge, keine Zeitleiste, keine Diagramme. Professionelle Oberflaechen bestehen groesstenteils aus fremden, gut getesteten Bausteinen — genau die sind hier technisch ausgeschlossen. Dazu 48 KB gewachsenes CSS ohne System (nach fünf Formaten sieht es aus wie fünf Apps) und keine Typen zwischen Kern und Format-Dateien. ENTSCHEIDUNG gegen eine gekaufte Admin-Vorlage (Metronic, Vuexy, DashboardPack & Co.): die verkaufen VERWALTUNGS-Oberflaechen (Tabellen, Formulare, Statistik-Kacheln). ReelForge ist ein Kreativ-Werkzeug (Vorschau, Regler, Mediathek) — davon waeren vielleicht 20 % brauchbar und 80 % fremde Struktur, die man nie wieder loswird. Stattdessen shadcn/ui als BAUKASTEN (Bausteine werden ins Projekt kopiert und gehören uns), shadcnblocks/21st.dev als Bausteinlager, optische Vorbilder von echten Kreativ-Werkzeugen statt von Verwaltungs-Vorlagen. VORGEHEN bewusst ohne grossen Rundumschlag: Phase 1 stellt nur die Bauweise um und ändert NICHTS am Aussehen — sieht danach alles aus wie vorher, ist das Fundament bewiesen. Das gerade gebaute Format-Register bleibt erhalten und wird mit Vite sogar sauberer (import.meta.glob statt Script-Tag-Reihenfolge). NEBENBEFUND: Das offizielle Design-Skill frontend-design war für dieses Projekt installiert, hing aber am alten Pfad instapi/scripts/reelforge und war seit dem Umzug still weg. Wieder angemeldet. Volle Roadmap in UI-ROADMAP.md.
Ziel geschaerft: All-in-one-Werkbank, gebaut von mehreren Sessions gleichzeitig2026-07-28
Festgelegt am 2026-07-28: ReelForge ist nicht ein Reel-Tool mit ein paar Formaten, sondern die Maschine, in die JEDE Art von Reel eingehaengt wird. Gebaut wird parallel — je Reel-Art eine eigene tmux-Session, alle im selben Ordner. Das ist der eigentliche Grund für den Umbau darunter: Sessions sehen die Änderungen der anderen nicht, und vorher haette JEDE neue Reel-Art fünf gemeinsame Dateien anfassen müssen. Der Beweis kam am selben Abend von allein — zwei Sessions standen gleichzeitig im Ordner und wurden beide gefragt, ob sie das Git-Repo anlegen sollen. REGELWERK dazu in CLAUDE.md (Reviere): Format-Ordner gehört der jeweiligen Session, Kern-Dateien nur der Session "Reelforge", vor dem Anfangen git status, nach dem Fertigwerden sofort committen und NUR das eigene Revier.
Format-Register: eine Reel-Art, ein Ordner2026-07-28
Umgesetzt 2026-07-28. Vorher hing eine neue Reel-Art an fünf gemeinsamen Dateien: if/elif in server.py, die FORMATS-Liste in data.jsx, je ein if/elif samt Baustein in controls.jsx und preview.jsx, und das Kachelbild in panels.jsx. Genau die Stellen, an denen sich parallel arbeitende Sessions gegenseitig überschreiben. Jetzt: formate/<id>/__init__.py (META + render) und formate/<id>/ui.jsx (Regler + Vorschau + Kachelbild). Beides wird beim Start automatisch eingesammelt — BEWUSST ohne Registrierungsliste, denn eine Liste waere wieder eine gemeinsame Datei. WER WAS BESTIMMT: Die Wahrheit über ein Format (Name, Symbol, Voreinstellungen, verfügbar ja/nein) steht in Python, weil der Server sie ohnehin kennen muss; die Oberflaeche liefert nur das Aussehen. Zwei gepflegte Listen würden garantiert auseinanderlaufen, und dann wählt man etwas aus, das der Server nicht kennt. Der Server bettet die Liste beim Seitenaufbau in die Seite ein statt sie nachzuladen — so ist sie da, bevor das erste Script läuft, ohne Wartezustand. RISIKOARM GEHALTEN: Die vier bestehenden Renderer wurden NICHT angefasst, die Format-Ordner reichen nur durch. Wer weiterbaut, holt sie Stück für Stück herueber. NEBENBEI: cloud_server prüft das Format jetzt schon beim Annehmen — vorher faehrt der schwere Container 80 Sekunden hoch, nur um mit "Unbekanntes Format" abzubrechen. GEPRÜFT statt gehofft: 10-Sekunden-Song komplett durch render_cli (gueltiges 1080x1920-MP4), alle JSX-Dateien mit demselben Babel uebersetzt, das der Browser laedt, und im echten Chromium alle sieben Kacheln plus Einstellungen, Vorschau und Kachelbild jedes aktiven Formats mit Inhalt gerendert. Dafür gibt es jetzt dauerhaft static/selbsttest.html — baut jede Reel-Art einmal auf und meldet, was kaputt ist.
Eigenes Git-Repo statt zurück ins instapi-Repo2026-07-28
Entscheidung Mert am 2026-07-28: /home/pi/reelforge bekommt ein eigenes Repo. Passt zur Pi-Konvention "ein Projekt, ein Ordner" und war der Sinn des Umzugs. Der Verlauf bis Commit 33ad6dd steckt weiter in der instapi-Historie, alles danach hier. DRINGEND WAR ES, weil ab jetzt mehrere Sessions gleichzeitig an denselben Dateien arbeiten — ohne Versionierung waere ein Überschreiben unwiederbringlich. OFFEN im instapi-Repo: dort stehen die 66 Dateien noch als "gelöscht" im Status. Das muss die instapi-Session einmal committen. Bis dahin gilt: wer dort "git restore ." macht, holt sich den alten Stand als Geisterordner zurück.
Vorgabe ist jetzt "Held — Schub", nicht mehr der alte Karaoke-Look2026-07-28
Umgestellt auf Mert-Ansage. Zwei Stellen, nicht eine: die Vorgabe in der Oberfläche (data.jsx) UND der Rückfall im Server — sonst bekämen Aufträge ohne das Feld weiter den alten Look, und Oberfläche und Server liefen auseinander. STOLPERFALLE: Die Vorgabe in data.jsx greift nur bei einem leeren Browser. Merts Browser hat einen gespeicherten Stand mit "klassisch", der gewinnt — man hätte die Umstellung nicht bemerkt. Deshalb eine einmalige Umstellung beim Laden, mit Merker, damit sie genau einmal passiert: wer danach bewusst auf "klassisch" zurückgeht, behält das.
Kernwort inhaltlich statt nach Länge — und was dabei NICHT half2026-07-28
Bisher wurde das grosse Wort einer Zeile nach Länge gewählt. Das ging regelmässig daneben: "will" ist länger als "Nacht" und trotzdem bedeutungslos. Neu entscheidet eine Liste von Funktionswörtern (Artikel, Pronomen, Präpositionen, Hilfs- und Modalverben, deutsch + englisch, weil gemischt gesungen wird), danach erst Länge und Position. BEWUSST OHNE SPRACHMODELL: das wären Kosten und Wartezeit pro Zeile für eine Entscheidung, die die Liste in den meisten Fällen genauso trifft. VERWORFEN, und das ist der lehrreiche Teil: zusätzlich die Seltenheit eines Wortes im Song zu gewichten ("was einmal vorkommt, sagt mehr als der Refrain"). Klingt vernünftig, ist bei Songtexten aber falsch herum — das Hauptmotiv wiederholt sich, WEIL es das Motiv ist. Am echten Songtext gemessen: mit Seltenheit änderten sich 4 von 27 Zeilen, davon 2 besser und 2 SCHLECHTER ("heute" statt "Nacht"). Ohne sie ändern sich 2 von 27, beide besser. Die Funktionswort-Liste macht die ganze Arbeit.
Schriftmessung war seit jeher kaputt — alle Captions rechneten mit einer Faustformel2026-07-28
Beim Bau der neuen Caption-Familie aufgefallen und mit Abstand der wichtigste Fund des Tages. Die Engine misst jedes Wort mit der echten Schrift aus, um Abstände und Umbrüche zu rechnen — dafür holt sie den Schriftpfad über fc-match. Der Pfad kam aber MIT Zeilenumbruch am Ende zurück, PIL warf "cannot open resource", und die Messung fiel still auf die Notfall-Schätzung zurück: Zeichenzahl × Größe × 0,5. Gemessen wurde also NIE etwas, obwohl genau das der Zweck der Funktion ist und ein früherer Commit ("Captions messen jetzt die echte Wortbreite") das behauptet hat. Aufgefallen ist es erst jetzt, weil eine Schreibschrift die Schätzung um das 1,6-Fache sprengt — das Wort lief sichtbar aus dem Bild. Bei Grotesk-Schriften lag die Faustformel zufällig nah genug dran, um nicht aufzufallen. Der Fix ist ein .strip(). Er ändert die Anordnung ALLER Modi (jetzt echte Breiten statt Schätzung); alle Vorschaubilder wurden neu erzeugt und geprüft. MERKSATZ: Wenn eine Messfunktion einen Rückfallwert hat, muss der Rückfall laut sein oder mindestens gezählt werden — sonst merkt man jahrelang nicht, dass gar nicht gemessen wird.
Neue Caption-Familie "Held" nach Mert-Vorlage2026-07-28
Mert hat ein Standbild aus einem fremden Reel geschickt, das ihm gefällt — ausdrücklich wegen Spacing und Schriften. Drei Dinge machen dort die Wirkung, und alle drei fehlten unseren bisherigen Modi: (1) ZWEI SCHRIFTEN HART GEGENEINANDER — ein grosses Schreibschrift-Wort mit langen Schwüngen als Held, dazu kleine fette Grotesk-Wörter. Kein Mittelding. (2) DIE WÖRTER VERZAHNEN SICH — sie stehen nicht nebeneinander, sondern greifen ineinander. Der Collage-Modus macht das GEGENTEIL: der schiebt Überlappungen per _entzerren auseinander. Hier wird die Überlappung gerechnet, nicht vermieden. (3) VERSETZTE GRUNDLINIEN — nichts steht auf einer Linie. Schrift: Great Vibes (aus drei Kandidaten gewählt — Pinyon Script zu zierlich, Alex Brush zu weich; Great Vibes trifft den harten Kontrast der Vorlage). Bewegung nach Mert-Vorgabe bewusst schlicht: schneller Schub von oben (220 ms) oder blosses Erscheinen. Keine Kurven-Akrobatik. ZWEI SACKGASSEN, die Zeit gekostet haben: Eine feste Punktgrösse für den Helden funktioniert nicht — "darüber" lief aus dem Bild, während "nachts" verloren wirkte. Die Grösse ergibt sich jetzt aus der gewünschten BREITE (82 % des Bildes). Und die Grössen der kleinen Wörter dürfen nicht fest sein, sondern werden aus der gemessenen HÖHE des Helden abgeleitet (Verhältnis rund 3,3–4,2 zu 1) — Punktgrössen sind zwischen Schriftarten nicht vergleichbar, eine Schreibschrift mit winziger x-Höhe wirkt bei 200pt kleiner als eine Grotesk bei 60pt.
Lato fehlte im Render-Abbild — Collage lief in der Cloud mit falschen Schriften2026-07-28
Nebenbefund: Der Collage-Modus ruft Lato Black/Light/Heavy/Medium. Auf dem Pi ist Lato als Systempaket da, im Container war es nie installiert — dort ersetzte libass es klaglos durch DejaVu. Wieder dieselbe stille Falle: es bricht nichts ab, es sieht nur falsch aus. fonts-lato ist jetzt im Abbild, und die Bau-Prüfung deckt alle sieben Schriftfamilien ab statt fünf.
Caption-Stile werden als Bild ausgewählt, nicht als Name2026-07-28
Die Auswahl war eine Liste mit Namen — "Mittelweg — Grotesk + Serif" sagt niemandem etwas, und bei Schrift entscheidet man nach Aussehen. Jetzt zeigt jeder Stil ein Vorschaubild, gruppiert nach Familie (Klassisch, Wort für Wort, Mittelweg, Schlicht, Collage). WICHTIG: Die Bilder sind mit der ECHTEN Engine und den echten Schriften gerendert (make_caption_previews.py), nicht per CSS nachgebaut. Eine Vorschau, die nur ungefähr passt, wäre schlimmer als keine — man wählt danach aus und bekäme etwas anderes. Erzeugt werden sie einmalig im Render-Container und als JPG mitcommittet (11 Stück, zusammen ~100 KB); zur Laufzeit rechnet nichts. Ändert sich ein Stil in caption_engine.py, muss das Skript neu laufen — sonst zeigt die Vorschau den alten Stand. Zwei Details, die den Ausschluss machen: (1) Alle Bilder bekommen DENSELBEN Ausschnitt, automatisch aus dem Textbereich aller Stile bestimmt — bei individuellem Zuschnitt sähe ein enger geschnittener Stil größer aus, als er ist. (2) Bei "Wort für Wort" verschwindet die ganze Gruppe, sobald das letzte Wort endet; mit kurzen Wortdauern war das Bild schon wieder leer, bevor alle Wörter standen (die ersten Vorschauen waren schwarz).
Caption-Timing: erst die Stimme trennen, dann den Text drauflegen2026-07-28
Bisher wurde der Songtext direkt auf den fertigen MIX gelegt — also auf Gesang PLUS Schlagzeug, Bass und Synths. Das Modell sucht Sprache in einem Klangbrei, entsprechend ungenau sitzen die Wörter. Neu trennt stable-ts erst die Gesangsspur heraus (demucs) und ordnet den Text auf der sauberen Stimme zu. GEMESSEN am 2026-07-28 an einem echten Song, mit zwei voneinander unabhängigen Maßstäben (beide aus der isolierten Gesangsspur gewonnen, also nicht im Kreis gemessen — der Maßstab ist reine Signalmessung, kein zweiter Spracherkenner): Versatz der Zeilenanfänge zum Gesangs-Einsatz 230 → 90 ms; Anteil der Einsätze näher als 150 ms 18 → 64 %; Versatz zum nächsten Silben-Einsatz 69 → 49 ms; Wörter, die in einer Gesangspause anfangen 2 → 0 %. VERWORFEN, jeweils mit Messung statt Bauchgefühl: Sprach-Erkennung (vad=True) macht es SCHLECHTER, sobald die Stimme getrennt ist (90 → 180 ms); Modell "medium" ist minimal besser (90 → 70 ms), kostet aber das 2,7-Fache; refine() (Nachschärfen) braucht das 6-Fache und ändert messbar nichts. PREIS: Die Trennung kostet Rechenzeit — auf dem Pi wuchs ein 45-Sekunden-Song von 46 auf 193 Sekunden. In der Cloud faellt das kaum ins Gewicht: derselbe Song braucht dort mit Trennung 64 Sekunden (8 Kerne statt 4, und die richtige Prozessor-Sorte). Abschaltbar über die Einstellung "stimmeTrennen". STOLPERFALLE beim Einbauen: demucs muss auf Version 4.0.1 festgenagelt werden. Neuere Ausgaben ziehen "sphn" nach, das für den Pi (arm64) kein fertiges Paket hat und einen Rust-Compiler verlangt. Außerdem liest die Trennung über soundfile ein, nicht über torchaudio — das verlangt inzwischen TorchCodec und fällt sonst mit ImportError aus. Nebenbei: Wörter, für die die Zuordnung keine Zeit liefert, fielen bisher stillschweigend raus (im Video fehlte mitten im Satz ein Wort). Sie werden jetzt zwischen ihre Nachbarn eingepasst.
Oberfläche in zwei Abteile geteilt — Reelmaker und Ordner2026-07-28
Vorher war alles eine einzige lange Seite: Song, Einstellungen, Vorschau UND die Liste aller fertigen Videos untereinander. Am Handy hiess das scrollen, bis man beim Gesuchten war. Jetzt zwei Abteile, umschaltbar in der Kopfzeile. "Ordner" zeigt zwei Regale: fertige Reels und die Hintergrund-Clip-Bibliothek, beide als Kachelraster mit Vorschaubild statt als Namensliste — bei Videos erkennt man am Bild in einer Sekunde, was man sucht, am Dateinamen ("Mila_3_Uhr_Naechte_lyrics_std_20260728_104255") nie. Damit die Kacheln nicht für jedes Bild Videodaten laden müssen, legt der Render-Job jetzt ein Standbild (thumb.jpg) neben das fertige Video; die Kachel greift darauf zu. Ältere Reels ohne Standbild behelfen sich weiter mit dem Video selbst (#t=1.5 holt genau ein Bild). Neuer Weg /api/thumb/<id>, dazu /api/clip/<name>, damit sich Hintergrund-Clips überhaupt ansehen lassen. Am Handy sind Abspiel- und Ladeknopf DAUERHAFT sichtbar (ohne Maus gibt es kein "hover") und das Abspiel-Symbol sitzt unten links statt mittig — mittig läge es genau auf der Caption des Reels. Geprüft im echten Browser auf 1440x900, 393x852 und 375x667: Umschalten funktioniert, kein Querscrollen, keine Fehler in der Konsole. NACHGEBESSERT am selben Tag auf Mert-Rückmeldung: Ein Klick auf eine Kachel sprang zuerst ins Abteil "Reelmaker", wo das Video in der dritten Spalte läuft — am Handy sitzt die weit unten, man musste also erst dorthin scrollen. Jetzt spielt das Video an Ort und Stelle im Ordner, in einer Ebene darüber (schließen per Escape, Klick daneben oder Knopf). Nachgemessen im Browser: der Spieler liegt auf allen drei Grössen komplett im Bild, ohne dass die Seite scrollt.
Caption-Engine angeschlossen — sie lief vorher gar nicht2026-07-28
Befund am 2026-07-28: caption_engine.py (vier Commits, sechs Kompositionen, Wort-für-Wort-Timing) wurde von KEINER Datei importiert. Die Arbeit war fertig, aber jeder Render brachte weiter den alten Karaoke-Look — ohne Fehlermeldung, weil nichts sie je aufgerufen hat. Angeschlossen über ein neues Zwischenstück caption_bridge.py, das die Whisper-Wörter in die vier Eingabeformen der Engine übersetzt. Zwei Regeln, die dort fallen: (1) Gruppen brechen an ATEMPAUSEN im Gesang statt stur alle drei Wörter — der alte Schnitt zerriss Sätze mitten im Satz; (2) das Kernwort ist das LÄNGSTE der Gruppe, bei Gleichstand das spätere. Ohne Bedeutungsanalyse ist Wortlänge der beste billige Näherungswert: Füllwörter sind kurz, Bedeutungsträger lang, die Pointe steht meist am Ende. Auswählbar sind 10 Stile im Format lyrics_std (Wort-für-Wort in 3 Varianten, Mittelweg in 3, Schlicht in 3, Collage). "Klassisch" bleibt der alte Look. BEWUSST OHNE stillen Rückfall: wer einen Stil wählt, bekommt ihn oder einen Fehler — genau die stille Falle, die hier schon zweimal zugeschlagen hat. Zwei Dinge fehlten für den Betrieb und sind jetzt drin: pysubs2 (schreibt die ASS-Dateien) stand in keiner Paketliste, und keine der Projektschriften war im Render-Abbild angemeldet — libass hätte sie klaglos durch DejaVu ersetzt, und die Engine misst jedes Wort vorher per fc-match aus, um die Abstände zu rechnen. Der Container prüft die fünf Schriften jetzt beim Bauen und bricht ab, wenn eine fehlt. Nebenbei korrigiert: die Variante "hart" versprach Versalien, schrieb aber in der Schreibweise des Songtexts.
Clip-Erzeugung: OpenArt PixVerse V6, fest auf 540p2026-07-27
Hintergrund-Clips entstehen über OpenArt (Merts Advanced-Abo, 12.000 Credits/Monat) per MCP-Anschluss — kein zweites Abo, keine API-Schluessel. Modell: PixVerse V6, text2video, 9:16, 5 s, ohne Ton. Es ist mit Abstand das guenstigste in OpenArts Liste (das nächste kostet 125 statt 70). FESTGELEGT am 2026-07-27: Aufloesung 540p statt 720p — 50 statt 70 Credits, also 29 % guenstiger. Ein Reel aus fünf Szenen kostet damit 250 Credits (~0,70 $), aus dem Monatskontingent werden 40 statt 29 Reels. Begruendung, warum die niedrige Aufloesung hier NICHT stoert: keine Gesichter im Bild (bewusst vermieden, dort scheitern die Modelle), kein Text im Clip (Captions werden später in voller Aufloesung eingebrannt), dunkles koerniges Material verzeiht Weichheit, und Instagram komprimiert ohnehin stark. Bei einzelnen Schluesselszenen kann man weiterhin auf 720p hochgehen. ACHTUNG: PixVerse lässt keinen festen Zufallswert setzen — derselbe Prompt liefert jedes Mal eine andere Aufnahme, ein sauberer A/B-Vergleich ist damit unmöglich.
Reels statt ganzer Musikvideos2026-07-27
Klarstellung 2026-07-27: Es werden KEINE kompletten Musikvideos gebaut, sondern kurze Reels vom besten Teil eines Songs (Hook), rund 15–25 Sekunden aus 3–5 Szenen. Das ändert die Dramaturgie: nicht Erzaehlbogen, sondern eine Kernszene mit zwei bis drei hinfuehrenden — weniger Schnitte, laengere Einstellungen, die staerkste Einstellung ans Ende. Kosten je Reel bei 540p rund 250 Credits.
Szenen aus dem Songtext statt abstrakter Tapete2026-07-27
Richtungsentscheidung 2026-07-27 nach mehreren verworfenen Anlaeufen: Der Hintergrund ist nicht mehr eine abstrakte Dauerschleife, sondern JEDE Zeile bekommt ihre eigene Szene, die zeigt was gesungen wird. Zwei Lesarten getestet — poetisch (keine Menschen, Raeume erzaehlen) und konkret (ein Mensch, aber NIE ein Gesicht: von hinten, im Gegenlicht, nur Haende). Mert hat die konkrete Fassung gewählt. Zwei Regeln, die den Ausschlag gaben: (1) nie ein Gesicht — dort scheitern die Modelle am zuverlaessigsten, die Vermeidung wirkt wie Regie statt wie Einschraenkung; (2) in JEDEM Prompt dieselbe Bildsprache (gleiche Filmemulation, gleiches Korn, kuehle Schatten mit warmen Lichtern) — ohne das sehen fünf Clips aus wie fünf verschiedene Filme statt wie ein Stück.
Videos ansehen und herunterladen2026-07-27
Früher lagen fertige Reels auf Merts PC in ~/Videos/Reelforge — in der Cloud gibt es keinen Ordner zum Aufmachen. Neu: (1) Kachel "Meine Videos" listet ALLE bisher gerenderten Reels (neueste oben, mit Datum und Größe), je Zeile ein Knopf zum Ansehen und einer zum Herunterladen. (2) Nach dem Rendern läuft das fertige Video direkt im Handy-Rahmen der Vorschau, mit "Zurück zur Vorschau". (3) Die beiden toten Knoepfe der Desktop-Zeit sind ersetzt — "Datei oeffnen" rief den Windows-Explorer, "Export" hatte gar keine Funktion. Server: /api/videos (Liste), /api/video/<id> (ansehen), /api/download/<id> (herunterladen), alle drei mit Bereichsabfragen, sonst lässt sich im Video nicht springen und Safari spielt es gar nicht erst ab. WICHTIG fuers Testen: der Chromium auf dem Pi kann H.264/AAC NICHT abspielen (freie Version ohne Lizenz-Codecs) und meldet dann "DEMUXER_ERROR_NO_SUPPORTED_STREAMS" — das ist KEIN Fehler der App. Byte-Genauigkeit stattdessen per curl gegen das Original prüfen.
Oberflaeche handytauglich gemacht2026-07-27
Die Oberflaeche war ein 3-Spalten-Raster in einer fixierten Buehne — auf dem Telefon unbedienbar. Geloest rein per CSS-Block (@media max-width 900px), die React-Bausteine blieben unangetastet und die Desktop-Ansicht ändert sich um kein Pixel: Spalten untereinander, die SEITE scrollt statt drei Kaestchen, Fenster-Knoepfe und Brotkrumen ausgeblendet, Eingabefelder auf 16px (darunter zoomt iOS beim Antippen rein und zerreisst das Layout), Tippziele mindestens 44px, Rand für die iPhone-Leiste unten. Render-Knopf steht jetzt FEST am unteren Bildschirmrand statt am Ende der Scrollstrecke. STOLPERFALLE dabei: position:fixed wirkte nicht, weil .col.preview einen transform (Einblend-Animation) UND einen backdrop-filter hat — beides macht die Spalte zum Bezugsrahmen, die Leiste landete bei Pixel 3218 statt 754. Der backdrop-filter kommt aus "body.glassy .col.preview", also aus einer staerkeren Regel als ".col.preview" — beide Selektoren müssen genannt werden. Geprüft per echtem Browser-Screenshot auf 393x852 und 375x667: kein Querscrollen, Leiste sichtbar.
Zugang per Passwort statt Google-Login (Google-Login gescheitert)2026-07-27
KORRIGIERT den Eintrag darunter: Der geplante Google-Login (IAP) lässt sich bei diesem Konto nicht in Betrieb nehmen. IAP antwortete dauerhaft mit 502 und der Meldung "Empty Google Account OAuth client ID(s)/secret(s)" — Google erzeugt den noetigen Anmelde-Schluessel bei privaten Gmail-Projekten ohne Organisation nicht automatisch, und die Schnittstelle, über die man ihn früher anlegen konnte (IAP OAuth Admin API), hat Google im Maerz 2026 abgeschaltet. Von Hand anlegbar waere er noch, ist aber Klick-Fummelei mit Henne-Ei-Problem bei der Weiterleitungs-Adresse. Entscheidung mit Mert am 2026-07-27: stattdessen ein Passwort vor der App. Umsetzung in cloud_server.py — Passwort und Sitzungsschluessel liegen im Google-Tresor (Secret Manager) und werden dem Dienst als Umgebungsvariable hereingereicht, NICHT im Code. Cookie nur über HTTPS, 30 Tage gueltig, Bremse nach 8 Fehlversuchen (5 Min Sperre) gegen Durchprobieren. Umstieg auf Google-Login bleibt jederzeit möglich.
Oeffentliche Web-App statt Tailscale-only2026-07-27
Zuschnitt geändert (2026-07-27, Mert-Wunsch): ReelForge soll auch auf Geraeten ohne Tailscale laufen. Daher liegt jetzt AUCH die Oberflaeche in der Cloud (Cloud-Run-Dienst "reelforge", Adresse https://reelforge-1085372544136.europe-west1.run.app), gesichert per Google-Login (IAP, seit 2026 ohne teuren Lastverteiler möglich, kostenlos). Nur Merts Konto ist freigeschaltet. WICHTIG: Oberflaeche und Render laufen in ZWEI getrennten Containern — Dockerfile.ui ist schlank (~250 MB, Bau 45 s, startet sofort), Dockerfile.render bleibt der schwere Brocken (4,9 GB, Kaltstart ~80 s), der nur zum Rendern hochfaehrt. Ein gemeinsamer Container haette bedeutet: 80 Sekunden Wartezeit, nur um die Oberflaeche zu oeffnen.
Cloud-Aufbau steht — gemessene Zahlen2026-07-27
Projekt reelforge-503709 (Region europe-west1/Belgien, EU-Datenhaltung). Bausteine: Zwischenspeicher gs://reelforge-503709-jobs (Ordner je Auftrag unter jobs/<id>/in bzw. /out, gemeinsame Clip-Bibliothek unter clips/), Render-Job "reelforge-render" (8 Kerne, 16 GB, existiert nur während er läuft), Oberflaechen-Dienst "reelforge". Zwei eng geschnittene Zugangskonten: reelforge-render darf NUR an den Zwischenspeicher, reelforge-ui darf an den Zwischenspeicher und den Render-Job wecken. Ausgabenlimit 5 EUR mit Mail-Warnung bei 50/90/100 %. GEMESSEN am 15-s-Testvideo: Cloud 48 s gegen Pi 105 s (Silbenzuordnung 21 s gegen 74 s), plus ~85 s Kaltstart beim ersten Render. Die alten Windows-Dialoge (Ordner-/Dateiauswahl per PowerShell, Explorer oeffnen) sind ersatzlos raus — im Browser sinnlos; Clips kommen jetzt aus der Bibliothek.
Umzug in die Cloud — Pi ist der Kopf, Cloud der Muskel2026-07-27
Entscheidung 2026-07-27: ReelForge verlaesst den Windows-PC. Neue Aufteilung — der Pi haelt Oberflaeche, Warteschlange und Dateien (Last nahe null) und uebergibt das fertige Video direkt an instapi; das schwere Rechnen läuft als Cloud-Job, der nur während des Renderns existiert (Google Cloud Run, Freikontingent 180.000 Prozessor-Sekunden/Monat ≈ 90 Musikvideos). Grund gegen den Pi als Render-Maschine: gemessene Hitzekurve unter Dauerlast — nach 2,5 Min reisst er die Hitzegrenze, nach knapp 4 Min drosselt er den Takt (2400 → 2256 MHz), Luefter da schon bei 10.100 U/min am Anschlag. Für ein 60-s-Reel (≈2 Min Arbeit) reicht der Pi, für geplante 3-Minuten-Videos mit KI-Clips (≈6 Min Volllast) nicht. Wichtig: die KI-Videos entstehen weiterhin bei Kling/Seedance/Higgsfield, nicht lokal — es kommt ein fertiges MP4 an. Deshalb wird KEINE Grafikkarte gebraucht, nur mehr CPU-Zeit.
Render-Kern von der Oberflaeche getrennt2026-07-27
Neu: render_cli.py rendert ohne Flask und ohne Fenster — nimmt dieselbe Job-JSON, die die Oberflaeche schon heute an /api/render/start schickt, schreibt Fortschritt in eine Statusdatei. Die bestehenden Renderer wurden dafür NICHT angefasst (server.py ist dank __main__-Schutz importierbar, ohne den Server zu starten) — bewusst risikoarm gehalten. Ausgabe-/Upload-Ordner jetzt per Umgebungsvariable (REELFORGE_OUTPUT_DIR / REELFORGE_UPLOAD_DIR) umstellbar, damit derselbe Code lokal und im Container läuft. Dazu Dockerfile.render: ffmpeg, Schriften, Whisper-Modelle fest eingebacken (spart ~40 s Anlauf pro Render), torch bewusst als CPU-Variante (sonst ~2,5 GB Treiber-Ballast). Auf dem Pi mit 15-s-Testsong geprüft: gueltiges 1080x1920-MP4, Umlaute korrekt, 9 Sekunden.
STILLE FALLE: ReelForge rendert bei fehlenden Paketen einfach schlechter weiter2026-07-27
Beim Containerbau zweimal reingefallen — unbedingt merken. Die Renderer fangen ImportError UND SystemExit ab und fallen dann auf _render_simple_caption_video zurück (schwarzer Hintergrund, keine Silbenzuordnung). Es kommt ein gueltiges MP4 raus, es bricht NICHTS ab — man merkt nur an der Optik, dass die gute Engine gar nicht lief. Zwei konkrete Ursachen gefunden und behoben: (1) torchaudio von PyPI passt nicht zur CPU-Variante von torch → laedt nicht → stable-ts tot; beide müssen aus derselben Quelle (download.pytorch.org/whl/cpu) kommen. (2) lyrics_video_ui.py importiert tkinter beim Laden (war mal ein Fenster-Programm, 68 Verwendungen) → ohne Paket "tk" im Abbild scheitert der Import. PRUEFREGEL nach jeder Änderung am Abbild: Import von lyrics_video_ui testen und auf "Align: 100%" im Renderlog achten — fehlt das, lief nur der Notfall-Renderer.
ReelForge liegt jetzt im Git-Repo2026-07-27
Der komplette Ordner war unversioniert — einzige Sicherung war Syncthing (und der PC ist meist aus). Am 2026-07-27 als Commit ins instapi-Repo aufgenommen: Backend, React-UI, alle Renderer, Schriften, Sounds. Arbeitsdateien (uploads/, _previews/, .stfolder/) bleiben per .gitignore draussen. Änderungen kuenftig mitcommitten.
Formatzahl korrigiert: 4 statt 3 aktiv2026-07-27
Manifest zaehlte 3 aktive Formate, im Code sind es 4 — spotify (spotify_video.py, _render_spotify in server.py) war nie eingetragen. Aktiv: lyrics_std, story_scroll, whatsapp_chat, spotify. Gesperrt bleiben pinterest, nachtfahrt, blackreveal.
WhatsApp-Chat: Feinschliff Animation + echte Sounds2026-06-22
Runde 2 Feedback (2026-06-22): (1) Drei Punkte "..." werden jetzt einzeln getippt (Auslassungszeichen … → drei echte Punkt-Tasten). (2) Tastatur slided smooth hoch (ease-out, 0,3s) statt schlagartig. (3) "tippt…" im Header während sie schreibt. (4) Echte WhatsApp-Sounds eingebaut: Empfangston (original WhatsApp-Notification), Sende-Swoosh, Tipp-Klicks pro Taste — Dateien in reelforge/sounds/, gemischt via build_chat_audio() zeitgenau zu den Szenen-Events. (5) Szene endet jetzt mit echtem SENDE-Moment (Antwort wird zur Bubble + Sende-Sound). _render_chat_frames gibt (n, switch, events) zurück. Profilbild = KI-Gesicht via Soul 2.0.
WhatsApp-Chat realistischer (Optik + Animation)2026-06-22
Format whatsapp_chat ueberarbeitet (2026-06-22): (1) echte Roboto-Schrift FEST mitgeliefert in reelforge/fonts/ (vorher Fallback auf DejaVu/Arial → Hauptgrund für unechten Look), inkl. NotoColorEmoji für Emojis. (2) Neuer 2025-Bubble-Stil: voll abgerundete Pillen OHNE Tail/Spitze, Schrift von +30% auf echtes Mass runter, Zeitstempel inline am Textende statt eigener Zeile. (3) Animation fluessig: FPS 30→60, Tipp-Punkte mit weichem 1,4-s-Puls, Nachricht blendet weich aus den Punkten ein. Farben waren schon exakt korrekt. Visuell auf dem Pi per Einzelframe+Clip geprüft. (4) Pixelvergleich gegen echten Android-Dark-Screenshot: Eingabeleiste verkleinert, Blasen-Padding enger, Timestamp baseline-buendig, Datums-Chip echter, Header-Trennlinie. (5) Bestehender Chat-VERLAUF von Anfang an sichtbar (nicht erste Nachricht). (6) Tippen menschlich: variable Geschw., Mini-Denkpausen, gelegentl. Tippfehler+Backspace-Korrektur (_simulate_typing). (7) Echte Android-Icons via Material-Icons-Font (Zurueck/Video/Anruf/ Menue/Senden/Mic/Klammer/Kamera/Smiley/Doppelhaken/WLAN/Signal/Akku) statt handgezeichnet. (8) Rundes Profilbild im Header (avatar_path; Default = KI-generiertes aesthetic Foto via Higgsfield Soul 2.0, passend zur deutschen Teen-Zielgruppe — kein GPT Image 2). (9) Langer Mehrtage-Verlauf mit Datums-Trennern (MO/DO/GESTERN/HEUTE), Chat UNTEN verankert wie echt. (10) Emoji-Fix: NotoColorEmoji ist Bitmap-Font (nur 109px) → in 109 rendern + skalieren. Bewusst NICHT geändert: exakte Hex-Farben (sind schon WhatsApp-genau). OFFEN (Stufe 2): Laenge auf 25s, Stille-Intro-Hook mit Chat-Sounds, Song-Drop.
Auto-Sync Pi<->PC via Syncthing statt scp2026-06-22
Schluss mit manuellem scp: Syncthing haelt den reelforge-Ordner zwischen Pi und Merts Windows-PC automatisch gleich (Zwei-Wege, sekundenschnell). Pi-Seite am 2026-06-22 eingerichtet: syncthing 1.29.5 als System-Dienst syncthing@pi (läuft nach Reboot weiter), Ordner-ID "reelforge" → /home/pi/instapi/scripts/reelforge, __pycache__ via .stignore ignoriert. Pi-Geraete-ID: JVZPKT3-LSRNH3I-R2CTGZD-XFZSLOY-32QCDTA-CPY4SZU-VWNRBKB-5BHO2Q3. Offen: Mert muss Syncthing auf dem PC installieren + koppeln (siehe tasks).
Doppelten Ordner reelforge_pc_stand aufgeloest2026-06-22
Unter /home/pi lag eine veraltete Kopie (Stand 29.05. 16:09) als reelforge_pc_stand — die landete nach einem Fehler faelschlich auf Merts PC, weniger Formate (kein Spotify), ältere UI. Am 2026-06-22 geprüft: jede gemeinsame Datei ist im echten Ordner neuer. Nur der Song-Upload + fontconfig waren unikat → in den echten Ordner kopiert. Alte Kopie geparkt als /home/pi/reelforge_pc_stand_ALT_kann_weg. EINZIGER gueltiger Pfad ist jetzt /home/pi/instapi/scripts/reelforge.
Renderer-Module ins Paket kopiert2026-05-29
lyrics_video_ui.py und whatsapp_video.py lagen früher ausserhalb des reelforge-Ordners und wurden vom scp -r nie mitkopiert — auf Windows lief deshalb nur der ASS-Fallback. Seit 2026-05-29 liegen Kopien direkt im Ordner. Jetzt werden die echten Renderer mitgeliefert.
pywebview statt reinem Browser2026-05-29
React-UI läuft als natives Programmfenster (pywebview), nicht im Browser-Tab. Grund: polierte Look mit Glow-Effekten und Live-Animation ist nur so möglich. Tkinter-Backup (reelforge_ui.py) bleibt als Notfall-Variante ohne pywebview.
Windows-FFmpeg-Fixes eingepflegt2026-05-29
server.py enthaelt 6 Fixes für Windows: Fontconfig-Patch, Pfad-Escaping, Umlaut-Sanitizing, Render in %TEMP%, ASS statt drawtext, subprocess ohne text=True. Lokal auf dem Pi getestet — Windows-Test steht noch aus.
Offene Aufgaben für Mert
- AKTE 09 auf TikTok und Instagram posten einmalig — REEL.mp4 und die fertigen Captions liegen in uploads/vox_fahrstuhl/ — auf TikTok und Instagram hochladen. Auf YouTube ist es schon oben.
- Stimmproben anhoeren und die Sprecherstimme entscheiden einmalig — In uploads/_stimmproben/ liegen acht Aufnahmen desselben Textes — anhören und sagen, welche Stimme es sein soll. Deine eigene ginge auch.
- Bilder in Flow erzeugen — Test-Reel, Probe und AKTE 03 neu einmalig — Drei Flow-Aufträge liegen bereit (Test-Reel, Fuenfer-Probe, AKTE 03). Anleitung und Befehl stehen im jeweiligen Ordner unter uploads/.
- Themen prüfen — 40 Anlässe warten auf dein Urteil routine — In der Themenliste stehen 40 Anlässe, die nur du beurteilen kannst — trägt die Geschichte oder nicht? Den Befehl gibt dir die ReelForge-Session.
- AKTE 01 ansehen und entscheiden, ob es hochgeht einmalig — uploads/vox_kelsey/REEL.mp4 ansehen und sagen, ob es hochgeht.
- Flow-Credits im Auge behalten, wenn mehrere Videos im Monat laufen routine — Einmal im Monat den Flow-Credit-Stand prüfen — Bilder kosten nichts, nur Video-Clips (7 je Clip).
- Entscheiden — Skripte mit ins Git-Repo nehmen einmalig — Freigeben, dass die Skripttexte mit ins Git-Repo wandern — aktuell liegen sie nur auf der SD-Karte.
- Strichfiguren — das erste Reel ansehen und entscheiden einmalig — Zwei Fassungen in uploads/strich_erinnerung/ ansehen (verschiedene Sprecher) und sagen, welche Richtung stimmt — oder ob das Format weg soll.
- Das Phantom-Reel im neuen Takt ansehen und entscheiden einmalig — uploads/vox_phantom_takt/REEL.mp4 ansehen und sagen, ob der schnellere Schnitt trägt.
- Entscheiden — Bilder nachbestellen, die ihre Information tragen einmalig — Entscheiden, ob die schwachen Bilder des Phantom-Reels neu bestellt werden (rund 40-120 Credits) oder die neue Regel erst ab dem nächsten Reel gilt.
- Eigene Session fuer die Archiv-Doku entscheiden einmalig — Entscheiden, ob die Session NeueIdee zu RF-Archiv wird oder aufgelöst — sie hat aktuell kein Revier.
- Optional entscheiden — Pexels-Zugang fuer moderne Clips einmalig — Optional: bei pexels.com/api einen Schlüssel holen, dann gibt es zusätzlich moderne Clips. Geht auch ohne.
- Entscheiden, ob Claude fest in ReelForge eingebaut wird einmalig — Entscheiden, ob Claude fest in ReelForge eingebaut wird oder Skripte weiter über den Chat entstehen.
- ReelForge-Passwort in den Passwortmanager legen einmalig — Das Passwort der ReelForge-Web-App in deinen Passwortmanager übertragen.
Infrastruktur2
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.
Datei-Sync zum PC — für jedes Projektseit 12.08.2026
Bis 12.08.2026 hatte nur ReelForge einen Abgleich mit deinem PC, von Hand in Syncthing eingerichtet. Jetzt ist es ein Handgriff für jedes Projekt: `python3 /home/pi/scripts/projekt_sync.py <projekt> --an` (bzw. `--aus`, `--liste`). Das Skript legt eine Ausnahmeliste an und gibt den Ordner für deinen PC frei; du musst die Freigabe dort einmal annehmen. Bewusst NICHT mitsynchronisiert: `.git` (Syncthing und Git streiten sich um Sperrdateien und zerlegen das Repo — Historie läuft über GitHub), Schlüsseldateien und laufende Datenbanken. Mit `--nur-senden` schreibt nur der Pi.
Web-Terminal · Diktier-Feld (Handy)seit 09.08.2026
Am Handy sitzt in der unteren Leiste ein Textfeld mit Mikrofon-Knopf. Gesprochenes oder getipptes landet erst dort und geht per Pfeil-Knopf genau einmal ans Terminal. Grund: direkt ins Terminal diktiert fügte die Handy-Tastatur den Satz zwei- bis dreimal ein (Composition-Ereignisse, die xterm.js mehrfach abschickt). Zusätzlich verwirft eine enge Notbremse identische Text-Blöcke während eines laufenden Diktats.
Web-Terminal · Diktieren auf dem iPhoneseit 09.08.2026
Auf iPhone/iPad wird bewusst NICHT die Spracherkennung des Browsers benutzt: in einer vom Homescreen gestarteten Web-App startet sie zwar (Knopf wird rot), liefert aber nie ein Ergebnis — Fehler in Apples Browser-Technik, von außen nicht zu reparieren. Der Mikrofon-Knopf holt dort stattdessen die Tastatur hoch; diktiert wird mit deren Mikrofon-Taste, was im normalen Textfeld zuverlässig läuft (setzt „Diktierfunktion" in den iOS-Einstellungen voraus). Auf Android/Chrome bleibt die Browser-Erkennung aktiv. Die Terminal-Seite wird seit dem gleichen Tag mit „no-store" ausgeliefert, weil iOS die Homescreen-App sonst auf einer alten Fassung festhält.
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)
Datei-Sync zum PCSyncthing (syncthing@pi) · pro Projekt schaltbar via scripts/projekt_sync.py
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.
CorePi🟢 läuftMerts persönliche Datenzentrale — Notizen, Aufgaben, Projekte, Ideen an einem Ort, als Web-App für Handy und Desktop (installierbar, ohne App Store). Kein Notion-Klon zum Selbstzweck, sondern der eine Speicher, an den sich ALLES andippt — die Pi-Projekte melden selbst Aufgaben rein, Gmail und Kalender fließen ein, und Friday (AssistPi) greift per Sprache auf dieselben Daten zu. Der Pi ist der Server, Zugang von unterwegs über den bestehenden Tailscale-Funnel. Ziel Stufe 2 - CorePi löst Notion als Merts Aufgaben-Oberfläche ab.
Merts persönliche Datenzentrale — Notizen, Aufgaben, Projekte, Ideen an einem Ort, als Web-App für Handy und Desktop (installierbar, ohne App Store). Kein Notion-Klon zum Selbstzweck, sondern der eine Speicher, an den sich ALLES andippt — die Pi-Projekte melden selbst Aufgaben rein, Gmail und Kalender fließen ein, und Friday (AssistPi) greift per Sprache auf dieselben Daten zu. Der Pi ist der Server, Zugang von unterwegs über den bestehenden Tailscale-Funnel. Ziel Stufe 2 - CorePi löst Notion als Merts Aufgaben-Oberfläche ab.
Funktionsweise
- Erfassen — Web-App (Handy/Desktop), Friday per Sprache, oder ein Pi-Projekt schreibt direkt rein
- Kern-API — eine einzige Schnittstelle für alles — lesen, schreiben, suchen. Kein Zweitweg an ihr vorbei.
- Objekt-Speicher — SQLite auf dem Pi. Alles ist ein Objekt (Notiz, Aufgabe, Projekt, Person, Idee) mit Typ, Text, freien Feldern und Verknüpfungen zu anderen Objekten.
- MCP-Server — dieselbe API nochmal als MCP — damit jede Claude-Instanz auf dem Pi direkt lesen/schreiben kann
- Anbindungen — Pi-Projekte melden Aufgaben rein, Gmail und Kalender fließen ein, Notion-Altbestand wird einmalig importiert
- Oberfläche — PWA (installierbare Web-App), ausgeliefert über Nginx, erreichbar über den bestehenden Funnel
- Backup — automatisch, ab Stufe 1 — nicht später. Der Kopf darf nicht auf einer einzelnen SD-Karte liegen.
Technik
SpeicherSQLite mit WAL, Volltextsuche über FTS5 — /home/pi/corepi/data/corepi.db
Kern-APIPython/FastAPI als systemd-Dienst "corepi" auf 127.0.0.1:8600, Token-Gate (X-CorePi-Token)
OberflächePWA — installierbar auf iOS/Android/Desktop, offline-fähig fürs Lesen und schnelle Erfassen (Stufe 2)
Zugangbestehender Nginx + Tailscale-Funnel + Passkey-Gate (terminal-auth), nichts Neues aufmachen. In Stufe 1 noch gar nicht nach aussen geöffnet — die API hört nur auf localhost.
Agenten-AnbindungMCP-Server "corepi" (stdio), global registriert in /home/pi/.claude.json — jede Claude-Instanz auf dem Pi hat die acht corepi_*-Werkzeuge
Backupstündlich per systemd-Timer "corepi-backup" (sqlite3 .backup + Integritätsprüfung), zusätzlich im zentralen Job backup_all_dbs.sh
Roadmap — jede Stufe für sich nutzbar
Stufe 1 — Speicher, Kern-API, Backupfertig 10.08.2026
SQLite-Modell steht, die Kern-API läuft als Dienst auf Port 8600, MCP-Server ist global registriert, stündliches Backup läuft und wurde einmal echt zurückgespielt. Jede Claude-Instanz auf dem Pi kann Notizen und Aufgaben lesen und schreiben. Noch keine Oberfläche. Offener Punkt - Backup nur lokal.
Stufe 2 — Die Appfertig 10.08.2026
Die App läuft unter /corepi/ - Aufgaben und Notizen erfassen, ansehen, abhaken, durchsuchen, auf dem Handy installierbar, offline nutzbar. Gefüllt mit den echten Aufgaben aus allen Projekt-Manifesten. Notion läuft bewusst NOCH parallel weiter - abgeschaltet wird erst, wenn Mert die App ein paar Tage im Alltag benutzt hat und sagt, dass sie trägt.
Stufe 3a — Datenschicht für Termine (fertig)fertig 10.08.2026
Schema-Version 3. Ein Termin ist ein Objekt mit typ='termin' und den Spalten beginn, ende, ganztags, ort, kalender, erinnerung_minuten; eine Aufgabe bekommt zusätzlich geplant_zeit und dauer_minuten und wird damit zum Zeitblock. Neuer Endpunkt GET /kalender?von=&bis= liefert Termine UND verplante Aufgaben in EINER Liste, mehrtägige Termine greifen über die Fenstergrenzen durch. Tabelle serien steht bereit, wird aber erst in 3d befüllt. Spalte extern_id ist für einen späteren Nur-Lesen-Abgleich freigehalten. 30 automatische Prüfungen unter scripts/pruefe_kalender.py, alle grün. Noch KEINE Oberfläche — Termine sind bisher nur über die API und den MCP-Server erreichbar.
Stufe 3b — Der Kalender (fertig)fertig 10.08.2026
Vier Ansichten mit einem Navigationsmodell: Jahr → Monat → Woche → Tag, überall hinein-, nirgends in eine Sackgasse. Am Schreibtisch Zeitraster mit Jetzt-Linie, Klick auf eine Uhrzeit legt dort einen Termin an (auf 15 Minuten gerundet), gleichzeitige Termine liegen nebeneinander statt übereinander. Am Handy dasselbe Monatsraster über die volle Höhe (seit 11.08.2026, davor halbhoch mit Tagesliste darunter), Wochenraster im Querformat. Wischen blättert, Tasten 1-4 wechseln die Ansicht, t springt auf heute. Kalender sind echte Objekte mit Namen und einer von sechs Farben und lassen sich einzeln ausblenden — genau der Schalter, den Apple in iOS 26 entfernt hat und der prompt vermisst wurde. Ein Termin ohne Titel wird beim Schließen wieder gelöscht, damit ein Fehlklick keine unsichtbaren Blöcke hinterlässt. 13 Prüfungen des Überlappungs-Verfahrens und 13 der Datumslogik (Sommerzeit, Monatsgrenzen, Schaltjahr), alle grün.
Stufe 3c — Aufgaben und Kalender verbunden (fertig)fertig 10.08.2026
Ein Objekt, drei Zustände: ohne Datum liegt eine Aufgabe im Vorrat, mit Tag steht sie in Heute und oben im Kalendertag, mit Uhrzeit zusätzlich als Block im Zeitraster. Keine Kopie, keine zweite Wahrheit. Aufgaben sind im Kalender ein eigener abschaltbarer Eintrag (wie Apples Erinnerungen) und tragen einen gestrichelten statt durchgezogenen Rand — eine Absicht ist keine Verabredung, und der Unterschied gehört sichtbar, aber leise. In Heute steht neu eine kompakte Terminleiste über der Aufgabenliste, die nur erscheint, wenn es Termine gibt: wer Aufgaben plant, ohne den Rahmen des Tages zu sehen, plant zwölf Stunden Arbeit in einen Tag mit sechs Stunden Terminen. Blöcke lassen sich im Raster verschieben und an der Unterkante in der Dauer ändern (15-Minuten-Raster); Aufgaben lassen sich direkt im Kalender abhaken, bleiben dabei aber stehen. Zentrale Neuerung im Code: alsZeitspanne() bringt Termine und verplante Aufgaben auf EINE Achse, sodass keine Zeichenfunktion mehr zwei Sonderfälle kennt. 12 Prüfungen dafür, alle grün.
Stufe 3d — Wiederholungen (fertig)fertig 10.08.2026
Vier Muster mit Intervall (täglich, wöchentlich, alle 2 Wochen, monatlich, jährlich), optional mit Enddatum. Die Termine werden ausgerechnet und als echte Zeilen abgelegt — 18 Monate im Voraus, täglich nachgeschoben (Timer corepi-serien, 04:12 Uhr). Ändern und Löschen fragen nach: nur dieser Termin oder alle künftigen; ein einzeln verschobener Termin wird als abweichend markiert und von späteren Zeit-Änderungen der Serie ausgenommen — inhaltliche Änderungen wie der Titel ziehen dagegen überall mit. Das ist die Rolle, die im iCalendar-Standard RECURRENCE-ID spielt, nur ohne dessen Ballast. Zwei Fehler kamen erst beim Testen heraus und sind behoben: monatliche Serien ab dem 31. wanderten ans Monatsende (jeder Termin wird jetzt vom Ursprung gerechnet, nicht vom Vortermin), und gelöschte Serien produzierten am nächsten Tag Geistertermine nach (verwaiste Serien werden aufgeräumt). 56 automatische Prüfungen in scripts/pruefe_serien.py und pruefe_serien_api.py, alle grün.
Stufe 3e — Notizen mit Markdown (fertig)fertig 10.08.2026
Notizen werden als Markdown im vorhandenen text-Feld gespeichert — kein neues Schema, weiterhin volltextsuchbar (ein fett geschriebenes Wort ist auffindbar), und lesbar, falls CorePi eines Tages nicht mehr läuft. Zwei Zustände statt eines Bausteineditors: im Ruhezustand gerendert, beim Tippen ein schlichtes Textfeld. Ein WYSIWYG-Editor auf contenteditable bricht zuverlässig Cursor, Rückgängig und Zwischenablage — und ein Block-Editor ist im Projektauftrag ausgeschlossen. Ausnahme: Häkchen lassen sich auch im Lesezustand anklicken, denn sie sind das Einzige, was man häufig anfasst, ohne schreiben zu wollen. [[Name]] im Text erzeugt beim Speichern eine echte Verknüpfung, sofern es das Ziel gibt — sonst bleibt es Text und lässt sich mit einem Klick anlegen (sonst wäre die Datenbank nach einer Woche voller Karteileichen aus Tippfehlern). Aus einer Hakenzeile wird per Knopf eine Aufgabe, verknüpft mit der Notiz. Rückverweise stehen im Detail, eigene Erwähnungen nicht — die stehen schon im Text.
Sicherheit — Notizen können kein HTML ausführenentschieden 10.08.2026
Der Markdown-Renderer escaped ZUERST alles und wendet die Regeln danach auf den escapten Text an. Damit kann aus einer Notiz niemals ausführbares HTML entstehen, auch nicht aus Text, den später ein fremdes System hier ablegt (Gmail-Anbindung, Notion-Import). Geprüft wird nicht, ob eine gefährliche Zeichenfolge im Text vorkommt — escaped ist sie harmlos —, sondern welche Tags der Renderer tatsächlich erzeugt: alles ausserhalb einer festen Erlaubnisliste wäre eine Lücke. 12 Angriffsproben in scripts/pruefe_markdown.js, das sich den Renderer direkt aus web/app.js schneidet und deshalb nie auf einer veralteten Kopie läuft.
Stufe 3f — Erinnerungen (fertig)fertig 10.08.2026
Web Push über den vorhandenen Service Worker. Im Detail eines Termins oder einer verplanten Aufgabe lässt sich ein Vorlauf setzen (pünktlich bis 1 Tag); ein Timer prüft alle fünf Minuten, was fällig ist, und schickt eine Meldung an alle angemeldeten Geräte. Der Fünf-Minuten-Takt ist bewusst grob — eine sekundengenaue Erinnerung nützt niemandem, ein jede Minute aufwachender Dienst hält den Pi wach. Drei Dinge sind ausdrücklich gelöst: abgelaufene Anmeldungen werden bei 404/410 weggeräumt (sonst sammeln sich Karteileichen), jedes Ereignis klingelt nur einmal (Tabelle push_gesendet), und wer den Pi kurz abschaltet, bekommt bis 45 Minuten Nachlauf — Älteres verwirrt nur. Die Erlaubnis wird NIE beim Start abgefragt, sondern erst beim Setzen der ersten Erinnerung: ein Dialog beim Öffnen wird reflexhaft weggeklickt und ist danach dauerhaft gesperrt. 19 Prüfungen in scripts/pruefe_erinnerungen.py auf einer eigenen Testdatenbank, alle grün.
Stufe 3g — iCal-Import (fertig)fertig 10.08.2026
scripts/ical_import.py holt Termine aus einer .ics-Datei oder von einer Adresse (Google und Apple bieten beides). Eigener kleiner Leser statt Bibliothek — gebraucht wird genau ein Vorgang. Drei Fallen sind ausdrücklich behandelt: das Ende ganztägiger Termine ist in der Datei EXKLUSIV (ein eintägiger Termin steht als 11. bis 12., sonst wäre alles einen Tag zu lang), Zeiten kommen als UTC oder mit Zonenangabe und werden mit der Sommerzeit umgerechnet, die AM TERMINTAG galt, und lange Zeilen sind im Standard umgebrochen und müssen zusammengesetzt werden. Zweimal ausführen legt nichts doppelt an: jeder Termin trägt seine Kennung aus der Quelldatei in extern_id. Wiederholungen werden übersetzt, soweit CorePi sie kennt — was darüber hinausgeht (etwa Mo/Mi/Fr), kommt als Einzeltermin mit ausdrücklichem Hinweis statt als stillschweigend falsche Serie. 19 Prüfungen, alle grün.
Stufe 3 abgeschlossen — was bewusst offen bleibtoffen
Ziehen aus dem Vorrat direkt ins Zeitraster. Das braucht eine Vorrat-Spalte neben dem Kalender, und ob die den Platz wert ist, zeigt sich erst im Alltagsgebrauch — der Weg über den Heute-Knopf und die Uhrzeit im Detail steht. Ebenso offen: kontinuierliches Scrollen durch die Monate (bei Apple läuft der nächste Monat unten weiter), Notiz-Anhänge und der Nur-Lesen-Abgleich mit fremden Kalendern.
Stufe 3+ — Anbindungenoffen
Die Pi-Projekte melden ihre Aufgaben selbst in CorePi (löst die tasks-Sektion in den Manifesten ab), Gmail fließt ein, der Notion-Altbestand wird einmalig importiert.
Stufe 4 — Friday (CorePi-Seite fertig)CorePi-Seite fertig 11.08.2026
Zwei Endpunkte, mehr braucht ein Sprachassistent nicht. GET /sprache/lage beantwortet 'Was steht heute an' mit EINEM vorlesbaren deutschen Satz — eine Liste kann ein Assistent nicht vorlesen, ohne dass der Zuhörer nach dem dritten Punkt aussteigt. POST /sprache/erfassen nimmt 'notier mir morgen den Steuerberater anrufen' und legt daraus ein Objekt mit Datum an. Die Deutung gab es bisher nur im Frontend, wo sie Friday nichts nützt; jetzt liegt sie in app/sprache.py und kennt zusätzlich die Wendungen, die gesprochen vorkommen und getippt nicht ('erinner mich daran', 'halb drei'). LATENZ nachgemessen statt behauptet: 2ms Median, 3ms im 95. Perzentil gegen den laufenden Dienst — Anforderung war 'deutlich unter einer Sekunde'. Gemessen wird das 95. Perzentil, nicht der Mittelwert: Ein Assistent, der in 5 von 100 Fällen hängt, fühlt sich kaputt an. Beim Bauen fiel ein echter Fehler auf, der ALLE Klienten betraf: POST /objekte legte eine Aufgabe ohne status an, und /heute filtert auf status='offen' — sie war also unsichtbar in der Datenbank. Das Frontend setzte den Status selbst, die Sprachschicht nicht. Die Vorgabe steht jetzt in der API. OFFEN und nicht CorePis Sache: AssistPi selbst gibt es auf diesem Pi nicht, nur ein Archiv vom 17.06.2026. Schnittstelle dokumentiert in FRIDAY.md.
Stufe 5 — Vorschläge (fertig)fertig 11.08.2026
Drei Sachen: Verknüpfungen vorschlagen, Eingang einsortieren, Tagesbriefing. ENTSCHEIDUNG, die alles andere bestimmt: KEIN Sprachmodell. Weder lokal (auf dem Pi verboten) noch über eine Schnittstelle nach draussen. Merts Notizen sind das Privateste auf dem Pi; sie an einen fremden Dienst zu schicken, damit dort jemand 'Verknüpfung vorschlagen' rechnet, ist ein schlechter Tausch — und keiner, den eine Instanz nebenbei trifft. Dazu: Friday hat eine Latenzanforderung, ein Aufruf nach draussen kostet das Hundertfache. Stattdessen inverse Dokumenthäufigkeit über die vorhandene Volltextsuche: Dass zwei Texte beide 'und' enthalten, sagt nichts; dass beide 'Backblaze' enthalten, sagt alles. An Merts echten Daten schlägt es bei 9 von 40 Objekten an — und die Treffer stimmen (ReelForge-Passwort ↔ Backup-Passwort, OpenArt-Credits ↔ Flow-Credits). DAS SCHWERSTE war nicht das Finden, sondern das SCHWEIGEN. Der erste Durchlauf schlug überall etwas vor, mit Begründungen wie 'gemeinsam: gibt, hast, etwa'. Drei Korrekturen: Stoppwörter werden auch NACH dem Kürzen geprüft (aus 'nichts' wird 'nicht'), ein Wort zählt nur bei höchstens zwei Vorkommen ODER unter einem Fünftel des Bestands, und ein EINZELNES gemeinsames Wort trägt nur, wenn es lang genug für einen Eigennamen ist. Ein Vorschlagsfeld, das immer etwas anzeigt, wird nach drei Tagen überlesen. Vorgeschlagen wird, nie angewendet — das prüft die Oberflächenprüfung ausdrücklich nach (keine schreibende Anfrage ohne Tipp). Grund: Die alte Manifest-Automatik hat jeder Aufgabe ein erfundenes Fälligkeitsdatum verpasst und CorePi damit fast ruiniert. Das Briefing endet mit GENAU EINEM Vorschlag. Eine Liste von fünf Ratschlägen liest niemand. Gemessen: Briefing 2ms, Einsortieren 25ms im 95. Perzentil (vorher 108ms — die Worthäufigkeiten wurden für jedes Objekt neu gezählt statt einmal).
Offene Aufgaben für Mert
- CorePi — Widget auf den Sperrbildschirm legen einmalig — Scriptable aus dem App Store laden, dann am iPhone https://pokepi.tail6ec256.ts.net/corepi/widget.html öffnen — die Anleitung steht dort.
- CorePi — Siri-Kurzbefehl anlegen und den Zugang einschalten einmalig — Sprach-Zugang auf dem Pi einschalten und am iPhone den Kurzbefehl anlegen. Schritt für Schritt: /home/pi/corepi/SIRI.md.
- CorePi — Sechs Punkte an die Gestaltungs-KI zurückgeben einmalig — Die sechs offenen Gestaltungs-Punkte stehen in /home/pi/corepi/GESTALTUNG_OFFEN.md — an die Gestaltungs-KI weitergeben.
- CorePi — Entscheiden, ob ein Sprachmodell mitrechnen darf einmalig — Entscheiden, ob CorePi ein Sprachmodell nutzen darf (bessere Zusammenfassungen, aber Notizen gehen raus und es kostet). Bis dahin bleibt alles auf dem Pi.
- CorePi — Entscheiden, ob AssistPi/Friday wiederbelebt wird einmalig — Entscheiden, ob AssistPi/Friday wiederbelebt, neu gebaut oder liegengelassen wird. Die Schnittstelle auf CorePi-Seite ist fertig.
- CorePi — Vorrat einmal durchgehen und den ersten Tag füllen einmalig — Im Bereich Vorrat einmal durchgehen und per Heute-Knopf auswählen, was wirklich ansteht.
- CorePi — App aufs Handy holen und ein paar Tage benutzen einmalig — App unter /corepi/ öffnen, auf den Home-Bildschirm legen und ein paar Tage benutzen.
- CorePi — Entscheiden, ob Notion als Aufgaben-Liste abgeschaltet wird einmalig — Nach ein paar Tagen mit der App sagen, ob sie trägt — dann wird Notion als Aufgaben-Liste abgeschaltet.
- Pi — Entscheiden, ob die anderen Projekte offen im Netz bleiben sollen einmalig — Entscheiden, ob Canvas, Handbuch, InvestPi und der Rest weiter ohne Anmeldung im Internet stehen dürfen oder wie CorePi hinter die Passkey-Anmeldung kommen.
- CorePi — Backup-Passwort ausserhalb des Pi ablegen einmalig — Den Backup-Schlüssel (RESTIC_PASSWORD in /home/pi/corepi/.env) in den Passwortmanager legen — sonst ist das Cloud-Backup wertlos, wenn die SD-Karte stirbt.
- CorePi — Notion-Projektseite anlegen einmalig — In der Notion-Datenbank "Raspberry-Pi-Projekte" eine Seite für CorePi anlegen und mir die Seiten-ID geben.
- CorePi — Entscheiden, was aus Notion übernommen wird einmalig — Einmal durchgehen, welche Notion-Inhalte nach CorePi wandern sollen und was Altlast ist.
Notizen
['Alles läuft über die Kern-API. Kein Projekt, kein Skript, keine Instanz schreibt direkt in die SQLite-Datei. Sonst ist die Zentrale nach drei Monaten inkonsistent.', 'Der Bau läuft in der eigenen tmux-Session "corepi", NICHT im Hub. Der Hub hat nur das Gerüst angelegt.', 'Der API-Token steht in /home/pi/corepi/.env (Rechte 600). Wer die API von einem Skript aus aufruft, schickt ihn im Kopf "X-CorePi-Token". Der MCP-Server holt ihn sich selbst aus dieser Datei.', 'Zustand prüfen - "systemctl status corepi" für den Dienst, "curl -s localhost:8600/gesundheit" für die Datenbank, /home/pi/corepi/data/backup.log für das Backup.', 'Die Wiederherstellung aus einer Sicherung wurde am 10.08.2026 einmal echt durchgespielt und funktioniert - Dienst stoppen, gunzip der Sicherung nach data/corepi.db, Dienst starten.', 'Notion bleibt in Betrieb, bis Mert nach ein paar Tagen App-Alltag sagt, dass umgelegt werden kann. Erst dann werden notion_tasks_sync.py und die Aufgaben-DB abgeschaltet - nicht vorher.', 'Die App hat seit 10.08.2026 eine eigene Kachel auf der Hub-Startseite, bewusst an erster Stelle (/home/pi/gateway/landing.html, Klasse "corepi"). Als einzige Kachel führt sie hinter das Passkey-Gate.', 'Die App liegt in web/ und wird von Nginx direkt ausgeliefert. Kein Übersetzungsschritt - Datei ändern, Seite neu laden. Nach Änderungen an app.js/app.css die Versionsnummer in index.html und sw.js hochzählen, sonst zeigt das Handy die alte Fassung aus dem Zwischenspeicher.']
Nichts gefunden.