Deine Content-Maschine in 5 Stationen.

KONTEXT
Ich baue mir eine Content-Maschine: Thema rein, fertiges 9:16-Video raus. Am Ende schaue ich kurz drüber und gebe frei. Ich bin der einzige Nutzer. Gesteuert wird alles in einem eigenen Dashboard.

Die Maschine hat fünf Stationen, jede ist ein eigener Schritt in einer Pipeline:
1. Augen (Radar): scannt Quellen nach Themen, über die gerade gesprochen wird, gruppiert und rankt die Funde, ich wähle ein Thema.
2. Autor (Hook Lab): schreibt mehrere Hook-Varianten und das Skript, prüft Fakten per Websuche, ich gebe frei.
3. Stimme: eigene Aufnahme oder ElevenLabs, danach Wort-Timing (bei ElevenLabs kommt es mit der Stimme, bei eigener Aufnahme zum Beispiel per whisper.cpp), damit Schnitte und Untertitel an Wörtern hängen.
4. Regisseur: eine KI plant aus Skript und Wort-Timing die Szenen und gibt eine strukturierte Szenen-Spec aus (Szenen, Held, Timing, Kamera). Die Spec wird per Zod validiert und bei Fehlern automatisch repariert.
5. Studio: Remotion rendert das 9:16-Video lokal. Ein Render-Worker auf meinem Rechner holt Aufträge aus dem Dashboard, lädt das Ergebnis hoch, ich sehe die Vorschau und gebe frei oder verwerfe.

Stack: Next.js (App Router, TypeScript), Tailwind CSS, Supabase (Auth + Postgres + Storage), Zod, Remotion. Ein Render-Worker als Node-Skript (TypeScript) im Repo.

ZIEL
Ein lauffähiges Grundgerüst, in dem ein Thema als ein Eintrag (content_item) durch alle fünf Stationen wandert. In diesem Schritt sind die Stationen nur Platzhalter mit Status, keine echte KI-Logik. Die echte Logik kommt Station für Station mit eigenen Prompts.

SCHRITTE
1. Lege das Projekt mit create-next-app an (TypeScript, Tailwind, App Router, src-Ordner, ESLint). Kein zusätzliches UI-Framework.
2. Installiere @supabase/supabase-js, @supabase/ssr und zod. Lege Supabase-Clients in src/lib/supabase/ an (browser.ts, server.ts, admin.ts mit `import 'server-only'`).
3. Auth: Login-Seite /login mit E-Mail und Passwort. Alle anderen Seiten erfordern eine Session (Middleware). Ausnahme: /api/reel-worker/*, das sich selbst per Token schützt.
4. Datenbank (supabase/migrations/001_pipeline.sql):
   - content_items: id uuid primary key default gen_random_uuid(), user_id uuid not null references auth.users(id) on delete cascade, title text not null, topic text, stage text not null default 'radar' mit check (stage in ('radar','autor','stimme','regisseur','studio','fertig','verworfen')), created_at, updated_at.
   - Row Level Security auf jeder Tabelle: Policy `user_id = auth.uid()` für select, insert, update, delete.
5. Oberfläche: Seite /pipeline mit fünf Spalten (Augen, Autor, Stimme, Regisseur, Studio), jede Karte ist ein content_item. Button "Neues Thema" legt manuell einen Eintrag an. Pro Karte ein Button "Weiter zur nächsten Station", der nur den Status ändert.
6. Lege eine CLAUDE.md an: Stack, Ordnerstruktur, Konventionen (user_id + RLS auf jeder Tabelle, Migrationen nummeriert, kein any, Zod an jeder Systemgrenze, keine Keys im Code).
7. Lege .env.example mit den Variablennamen an (NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY). Keine echten Werte.

DATEISTRUKTUR (Ziel)
src/app/login/page.tsx
src/app/pipeline/page.tsx
src/app/api/reel-worker/ (leer, kommt in Station 5)
src/lib/supabase/{browser,server,admin}.ts
src/lib/stages.ts (Liste der fünf Stationen, einzige Quelle für Namen und Reihenfolge)
supabase/migrations/001_pipeline.sql
CLAUDE.md, .env.example

AKZEPTANZKRITERIEN
- npm run build und npm run lint laufen ohne Fehler durch.
- Ohne Login lande ich auf /login, danach auf /pipeline.
- Ich lege ein Thema an und schiebe es durch alle fünf Spalten.
- Ein zweiter Test-Account sieht meine Einträge nicht (RLS-Test).
- Im Repo steht kein Key.

REGELN
Zeige mir zuerst das Datenmodell und warte auf mein OK, bevor du die Migration schreibst. Die Migration spiele ich selbst ein. Baue nicht mehr als beschrieben.

KONTEXT
Grundgerüst steht (Next.js, Supabase, Pipeline-Seite, content_items, CLAUDE.md). Ich baue jetzt Station 1 "Augen" (Radar): Es sammelt Funde aus Quellen, über die gerade gesprochen wird, gruppiert und rankt sie, und ich wähle ein Thema, das als content_item in die Pipeline geht.

EINGABE
Eine Liste von Quellen, in der Oberfläche pflegbar. Typen: github, reddit, youtube, hackernews, rss, instagram. Pro Quelle: Typ, Name, Adresse oder Suchbegriff, aktiv ja/nein. Zusätzlich kann ich einen Fund von Hand anlegen (Titel, Link, Zusammenfassung), zum Beispiel aus einer Recherche mit Claude Code und Agent Reach.

AUSGABE
Eine Rangliste von Themen-Clustern. Jedes Cluster: Titel, kurze Zusammenfassung, die zugehörigen Funde mit Link, eine Rangzahl. Ein Klick auf "Thema wählen" legt ein content_item (Stage 'autor') mit dem Thema an.

DATENBANK (supabase/migrations/002_radar.sql)
- radar_sources: user_id, type (check auf die sechs Typen), name, target, active boolean default true, last_error text.
- radar_items: user_id, source_id (nullable, weil von Hand angelegte Funde keine Quelle haben), title, url, summary, found_at, cluster_id (nullable).
- radar_clusters: user_id, title, summary, rank integer, created_at, chosen boolean default false.
- RLS wie überall: user_id = auth.uid().

LOGIK
1. src/lib/radar/connectors/<typ>.ts: pro Quelltyp ein Connector mit derselben Signatur `fetchItems(source): Promise<RawItem[]>`. Eine reine Funktion übersetzt die Fremdantwort in RawItem (testbar ohne Netz), eine dünne Hülle holt sie. Beginne mit den Connectors, die ohne Zugangsdaten gehen:
   - rss: beliebiger RSS- oder Atom-Feed, mit der Bibliothek rss-parser. Jeder Feed wird einzeln abgefangen.
   - hackernews: die Suche von Algolia (https://hn.algolia.com/api/v1/search?tags=story&query=...), gefiltert nach Alter und Mindestpunkten. Lies zuerst die Doku.
   - github: offizielle REST-Schnittstelle, Repository-Suche (https://api.github.com/search/repositories), gefiltert nach Mindest-Sternen und letzter Aktivität, sortiert nach Sternen. Eigener User-Agent im Header. Ein Token aus der Umgebung ist optional und hebt nur das Limit an (ohne Token 10 Suchen pro Minute, mit Token 30, prüfe die aktuelle Doku).
   - reddit: Subreddit-Feed per RSS (https://www.reddit.com/r/<name>/.rss), mit eigenem User-Agent. Nutze nicht die .json-Adressen, sie liefern ohne Anmeldung oft einen Fehler 403. Auch der RSS-Weg kann von Server-IPs blockiert werden: Dann ist das eine Fehlermeldung pro Quelle, kein Grund für Wiederholungen. Der zuverlässige Weg wäre die offizielle API mit App-Registrierung (OAuth), baue sie jetzt nicht.
   Die übrigen legst du als Stubs an, die einen klaren Fehler "noch nicht verbunden" liefern:
   - youtube: offizielle YouTube Data API v3 (search.list, danach videos.list für die Zahlen), braucht einen API-Schlüssel (YOUTUBE_API_KEY, nur Name in .env.example). search.list verbraucht deutlich mehr Kontingent als videos.list, lies die Quota-Doku.
   - instagram: nur über die offizielle Instagram-API (Business Discovery der Graph API oder eigenes Creator-Konto). Baue das jetzt nicht.
2. Prüfe vor jedem Connector die offiziellen Nutzungsbedingungen der Plattform und notiere das Ergebnis in docs/radar-quellen.md (Quelle, Schnittstelle, Bedingungen, Limits). Kleine Abfragen, keine Schleifen über viele Seiten, kein Umgehen von Sperren. Ein 403 oder 429 ist eine Meldung pro Quelle (in radar_sources.last_error), kein Grund für Wiederholungen. Fällt ein Connector aus, laufen die anderen weiter.
3. Agent Reach (https://github.com/Panniantong/agent-reach, MIT) ist ein Werkzeug für Agenten wie Claude Code, keine Bibliothek. Installiere es nicht selbst. Beschreibe in docs/radar-quellen.md in fünf Zeilen, wie ich es installiere (die Anleitung im Repo unter docs/install.md) und welche Kanäle ohne Zugangsdaten laufen (Web, YouTube, RSS, GitHub über gh). Reddit, Instagram und Facebook brauchen eine eingeloggte Browser-Sitzung (OpenCLI), X braucht Cookies. Frage mich, bevor du Cookies oder Browser-Sitzungen anfasst. Ergebnisse einer solchen Recherche lege ich über das Formular "Fund von Hand anlegen" ins Radar.
4. src/lib/radar/cluster.ts: gruppiert Funde mit ähnlichem Thema. Starte mit einem einfachen Wortvergleich (Überlappung der Wörter in Titel und Zusammenfassung, Schwelle als Konstante). Ein KI-Aufruf mit Zod-Schema für die Antwort gibt jedem Cluster Titel und Zusammenfassung. Ein Cluster heißt nur dann "Trend", wenn mindestens zwei Funde von verschiedenen Quellen oder Urhebern darin liegen, sonst "Entdeckung".
5. src/lib/radar/rank.ts: ordnet die Cluster. Einfache, nachvollziehbare Regel (zum Beispiel Zahl der Quellen, in denen das Thema auftaucht, plus Aktualität). Die Regel steht als Kommentar oben in der Datei.
6. Route src/app/api/radar/scan/route.ts: läuft nur auf Klick (POST, eingeloggt). Kein automatischer Lauf, bis du die Kosten pro Scan kennst. Jeder KI-Aufruf wird in einer Tabelle ai_runs (Schritt, Modell, Tokens, Zeitpunkt) protokolliert.
7. Seite /radar: Quellenliste, Formular "Fund von Hand anlegen", Button "Jetzt scannen", darunter die Rangliste mit "Thema wählen".

AKZEPTANZKRITERIEN
- Mit mindestens einer RSS-Quelle liefert ein Scan Funde und mindestens ein Cluster.
- Ein Hacker-News-Feed liefert Funde, ohne dass ein Schlüssel in der Umgebung steht. Ein Reddit-Feed liefert Funde oder eine klare Fehlermeldung pro Quelle.
- Ein von Hand angelegter Fund wird beim nächsten Scan mit geclustert.
- "Thema wählen" erzeugt genau ein content_item in der Spalte Autor.
- Ein kaputter Connector bricht den Scan nicht ab: Der Fehler steht pro Quelle in der Oberfläche, die anderen laufen weiter.
- Ohne Klick läuft nie ein KI-Aufruf.
- npm run build und npm run lint laufen durch, keine Keys im Code.

REGELN
Zeige mir zuerst das Datenmodell und warte auf mein OK. Die Migration spiele ich selbst ein. Kein any, Zod an jeder Systemgrenze.

KONTEXT
Radar steht, ein gewähltes Thema landet als content_item in der Spalte Autor. Ich baue jetzt Station 2 "Autor" (Hook Lab): Aus dem Thema entstehen mehrere Hook-Varianten und das Skript. Die Fakten werden per Websuche geprüft, dann gebe ich frei.

EINGABE
content_item mit Thema und den Radar-Funden dazu (Titel, Link, Zusammenfassung).

AUSGABE
- Fünf Hook-Varianten, jede mit einem anderen Mechanismus (Text, Mechanismus in einem Wort, zum Beispiel Nutzen, Neugier, Gegenthese, Problem). Ich wähle eine.
- Ein Skript zum gewählten Hook (gesprochener Text, in kurzen Sätzen, mit Absätzen als Sinnabschnitte).
- Ein Faktencheck: pro Behauptung im Skript ein Eintrag mit Quelle (Link) und Status belegt oder offen. Offene Behauptungen werden mir rot angezeigt.
- Freigabe-Button (nur nach bestandenem Faktencheck). Erst danach geht das content_item zur Station Stimme.

DATENBANK (supabase/migrations/003_autor.sql)
- content_hooks: user_id, item_id, text, mechanism, chosen boolean default false.
- content_scripts: user_id, item_id, version integer, text, approved boolean default false, created_at.
- fact_checks: user_id, script_id, claim, source_url (nullable), status check in ('belegt','offen').
- RLS wie überall.

LOGIK
1. src/lib/autor/hooks.ts: ein KI-Aufruf, Antwort per Zod-Schema validiert (Array von { text, mechanism }). Bei ungültiger Antwort einmal automatisch mit der Fehlermeldung reparieren lassen, dann abbrechen mit klarer Meldung.
2. src/lib/autor/script.ts: schreibt das Skript zum gewählten Hook. Ton und Regeln (Duzen, kurze Sätze, keine Floskeln) stehen als Konstante oben in der Datei, damit ich sie anpassen kann.
3. src/lib/autor/factcheck.ts: zerlegt das Skript in prüfbare Behauptungen und prüft jede per Websuche (Such-Tool des KI-Anbieters). Gibt Quelle und Status zurück. Erfinde nie eine Quelle: Ohne Fund ist der Status 'offen'. Begrenze die Zahl der Websuchen pro Aufruf und die Menge an Text, die pro Seitenabruf geladen wird, sonst werden Faktenchecks teuer.
4. Routen unter src/app/api/autor/: hooks, script, factcheck, approve. Jede läuft nur auf Klick, jeder KI-Aufruf geht in ai_runs.
5. Seite /pipeline/[id]/autor: Hooks nebeneinander, Auswahl, Skript editierbar, Faktencheck-Liste, Freigabe.
6. Freigabe erst, wenn ein Hook gewählt ist, das Skript gespeichert ist und der Faktencheck gelaufen ist, ohne dass eine Aussage offen bleibt. Ausnahme: Ein Skript ohne Tatsachenbehauptungen darf ich bewusst ohne Faktencheck freigeben (eigener Button).

AKZEPTANZKRITERIEN
- Aus einem Thema entstehen fünf Hooks, ich wähle einen, es entsteht ein Skript.
- Jede Behauptung im Faktencheck hat eine Quelle oder ist als offen markiert.
- Eine absichtlich kaputte KI-Antwort (im Test gemockt) wird einmal repariert oder sauber abgelehnt.
- Nach Freigabe steht das content_item in der Spalte Stimme.
- npm run build und npm run lint laufen durch.

REGELN
Zeige mir zuerst das Datenmodell und warte auf mein OK. Migration spiele ich selbst ein. Kein any.

KONTEXT
Das Skript ist freigegeben. Ich baue jetzt Station 3 "Stimme": Aus dem Skript entsteht eine Audiodatei (eigene Aufnahme oder ElevenLabs), danach das Wort-Timing, damit Schnitte und Untertitel an Wörtern hängen.

EINGABE
Freigegebenes Skript. Zwei Wege: (a) ich lade eine eigene Aufnahme hoch, (b) die Stimme wird per ElevenLabs aus dem Skript erzeugt (nur auf Klick, Kosten sichtbar machen, bevor ich klicke).

AUSGABE
- Eine Audiodatei im Supabase Storage (privater Bucket).
- Eine Timing-Datei (JSON): Liste von Wörtern mit Startzeit und Endzeit in Sekunden, dazu die Gesamtdauer.

DATENBANK (supabase/migrations/004_stimme.sql)
- content_voiceovers: user_id, item_id, script_id, source check in ('upload','elevenlabs'), audio_path, duration_seconds, status check in ('neu','audio_da','timing_da','fehler'), error text.
- word_timings: user_id, voiceover_id, words jsonb (Array von { word, start, end }).
- Privater Storage-Bucket "voice" mit Policy pro Nutzer. RLS wie überall.

LOGIK
1. src/lib/stimme/elevenlabs.ts: Text rein, Audio raus. API-Key nur serverseitig aus der Umgebung (ELEVENLABS_API_KEY, Name in .env.example, kein Wert). Stimme und Modell als Einstellung, nicht fest im Code. Lies die aktuelle ElevenLabs-Doku, bevor du die API ansprichst.
2. Upload-Weg: Datei-Upload nach Storage, Dauer auslesen.
3. Wort-Timing, ElevenLabs-Weg: Der Endpunkt text-to-speech/{voice_id}/with-timestamps liefert das Audio (base64) und für jedes Zeichen Start- und Endzeit. Rechne daraus Wörter mit start und end (ein Wort endet am Leerzeichen) und validiere sie mit dem Zod-Schema src/lib/stimme/timing-schema.ts (Wörter, start, end, Dauer). Lies zuerst die aktuelle ElevenLabs-Doku zu diesem Endpunkt. Es ist kein zweiter Transkriptions-Schritt nötig.
   Wort-Timing, Upload-Weg: Nur für eigene Aufnahmen legst du ein Skript scripts/transcribe.ts an, das whisper.cpp (https://github.com/ggml-org/whisper.cpp, MIT) mit Wort-Zeitstempeln aufruft und nach demselben Schema validiert ausgibt. Das läuft lokal auf meinem Rechner (im Render-Worker aus Station 5), nicht auf Vercel. Lies zuerst die README von whisper.cpp und `whisper-cli --help` und nutze die dort beschriebenen Optionen für JSON-Ausgabe und Wort-Zeitstempel. whisper-cli liest nur 16-bit-WAV: Das Skript wandelt die Audiodatei vorher mit ffmpeg um (16 kHz, mono). Für Deutsch ein mehrsprachiges Modell nehmen (ohne .en im Namen). Beschreibe in der README, wie man whisper.cpp und ffmpeg installiert und ein Modell lädt, nach der offiziellen Anleitung im Repo.
4. Prüfung: Die Wörter im Timing müssen zum Skript passen (wichtig beim Upload-Weg). Weicht die Wortzahl stark ab, zeige eine Warnung statt still weiterzumachen.
5. Seite /pipeline/[id]/stimme: Upload oder "Mit ElevenLabs erzeugen", Audio-Player, Timing-Status, Button "Weiter zum Regisseur" (erst aktiv, wenn Timing da ist).

AKZEPTANZKRITERIEN
- Ein Upload erzeugt eine abspielbare Audiodatei im privaten Bucket.
- Ein ElevenLabs-Lauf liefert ein Timing-JSON, das das Zod-Schema besteht, ohne zusätzlichen Transkriptions-Schritt.
- scripts/transcribe.ts liefert für eine eigene Beispielaufnahme ein Timing-JSON, das das Zod-Schema besteht.
- Ohne Klick wird nie ElevenLabs aufgerufen.
- Fehlt der API-Key, zeigt die Oberfläche eine klare Meldung statt eines Absturzes.
- npm run build und npm run lint laufen durch, kein Key im Repo.

REGELN
Zeige mir zuerst das Datenmodell und warte auf mein OK. Migration spiele ich selbst ein. Kein any.

KONTEXT
Skript, Audio und Wort-Timing liegen vor. Ich baue jetzt Station 4 "Regisseur": Eine KI plant aus Skript und Wort-Timing die Szenen und gibt eine strukturierte Szenen-Spec aus. Die Spec wird per Zod validiert und bei Fehlern automatisch repariert. Bei mir läuft die KI über `codex exec` (Codex CLI) auf meinem Rechner.

EINGABE
Skript (Text), Wort-Timing (Liste aus { word, start, end }), Gesamtdauer.

AUSGABE
Eine Szenen-Spec als JSON, die das Zod-Schema besteht:
- scenes: Array. Pro Szene: id, start (Sekunden), end (Sekunden), hero (was im Bild im Mittelpunkt steht, kurzer Text), camera (zum Beispiel 'static', 'push-in', 'pan-left'), text_on_screen (optional), word_range (Index erstes und letztes Wort aus dem Timing).
- Regeln, die das Schema prüft: Szenen sind lückenlos und überlappungsfrei, die erste beginnt bei 0, die letzte endet bei der Gesamtdauer, jede Szene liegt auf Wortgrenzen.

DATEISTRUKTUR
src/lib/director/scene-spec.ts (Zod-Schema + abgeleiteter TypeScript-Typ, einzige Quelle der Wahrheit)
src/lib/director/prompt.ts (baut den Prompt für die KI aus Skript und Timing)
src/lib/director/run.ts (ruft die KI auf, validiert, repariert)
scripts/director.ts (CLI: Skript-Pfad und Timing-Pfad rein, scene-spec.json raus)
src/lib/director/__tests__/ (Tests)

LOGIK
1. run.ts ruft die KI über `codex exec` auf (Kindprozess), gibt den Prompt über stdin oder als Argument, fordert ausschließlich JSON an und liest die Ausgabe. Lies zuerst die aktuelle Dokumentation der Codex CLI zu `codex exec` und nutze die dort beschriebenen Optionen. Bei mir läuft es so (gegen `codex exec --help` geprüft): `codex exec --skip-git-repo-check --ephemeral -s read-only -C <leeres Temp-Verzeichnis> -o <Ausgabedatei> "<Prompt>"`, optional mit `--output-schema <schema.json>` und `-m <Modell>`. Die Antwort liest du aus der Ausgabedatei. Der Prozess bekommt ein Zeitlimit. Der Aufruf ist austauschbar gekapselt (eine Funktion `callModel(prompt): Promise<string>`), damit man später einen anderen Anbieter einsetzen kann.
2. Validierung: JSON parsen, dann mit dem Zod-Schema prüfen.
3. Reparatur: Schlägt die Validierung fehl, geht die Zod-Fehlerliste zusammen mit der kaputten Ausgabe zurück an die KI mit der Bitte, nur das JSON zu korrigieren. Höchstens zwei Reparaturversuche, danach klarer Fehler mit der letzten Fehlerliste.
4. Ergebnis wird als scene_specs-Zeile gespeichert (user_id, item_id, spec jsonb, attempts integer, created_at). Migration supabase/migrations/005_regisseur.sql, RLS wie überall.
5. Seite /pipeline/[id]/regisseur: Button "Szenen planen", Anzeige der Szenen als Zeitleiste, Hinweis, wie viele Reparaturversuche nötig waren, Button "Weiter zum Studio".

AKZEPTANZKRITERIEN
- Tests laufen durch: gültige Spec besteht, Spec mit Lücke, Überlappung oder falscher Gesamtdauer fällt durch.
- Test mit gemockter KI: erste Antwort kaputt, zweite korrekt, es wird genau einmal repariert.
- Test mit dauerhaft kaputter Antwort: nach zwei Versuchen ein klarer Fehler, kein Endlosloop.
- scripts/director.ts erzeugt für ein Beispiel eine scene-spec.json, die das Schema besteht.
- npm run build, npm run lint und npm test laufen durch.

REGELN
Zeige mir zuerst das Zod-Schema und warte auf mein OK, bevor du den Rest baust. Kein any.

KONTEXT
Szenen-Spec, Audio und Wort-Timing liegen vor. Ich baue jetzt Station 5 "Studio": Remotion rendert das fertige 9:16-Video lokal. Ein Render-Worker auf meinem Rechner holt Aufträge aus dem Dashboard, rendert, lädt das Ergebnis hoch, im Dashboard sehe ich die Vorschau und gebe frei oder verwerfe.

EINGABE
scene_specs (Station 4), Audio-Datei, word_timings.

AUSGABE
- Eine MP4 im Format 1080x1920 (9:16) im privaten Storage-Bucket "renders".
- Im Dashboard: Status des Auftrags, Vorschau-Player, Buttons "Freigeben" und "Verwerfen".

DATEISTRUKTUR
remotion/ (eigenes Remotion-Projekt im Repo)
  src/Root.tsx (Composition "Reel", 1080x1920, fps als Konstante)
  src/Reel.tsx (liest die Szenen-Spec und baut pro Szene eine Sequence)
  src/Captions.tsx (Untertitel Wort für Wort aus dem Timing)
worker/
  index.ts (Polling-Schleife)
  render.ts (Remotion-Render per @remotion/renderer)
src/app/api/reel-worker/ (Routen: claim, upload-url, complete, fail)
supabase/migrations/006_studio.sql

DATENBANK
render_jobs: user_id, item_id, spec_id, status check in ('wartet','läuft','fertig','fehler','freigegeben','verworfen'), video_path, error text, created_at, updated_at. RLS wie überall.

LOGIK
1. Button "Rendern" im Dashboard legt einen render_job mit Status 'wartet' an.
2. Der Worker läuft nur auf meinem Rechner (`npm run worker`). Er kennt keine Datenbank-Keys. Er spricht nur mit den Routen unter /api/reel-worker/* und authentifiziert sich per Bearer-Token. In seiner .env stehen nur REEL_DASHBOARD_URL und REEL_WORKER_TOKEN (Namen in .env.example, keine Werte). Das Token prüft die Route serverseitig mit einem konstanten Vergleich.
3. Ablauf im Worker: next-job holen (setzt Status atomar auf 'läuft'), Audio und Spec laden, mit Remotion rendern, per vorsignierter Upload-URL hochladen, complete melden. Bei Fehler: fail mit Meldung. Kein Job: kurz warten, nochmal fragen.
4. Remotion-Komposition: Dauer kommt aus der Spec (calculateMetadata). Jede Szene wird als Sequence auf den Zeiten aus der Spec gespielt, die Audiodatei läuft durch, Untertitel kommen aus dem Wort-Timing. Beachte die Remotion-Regeln für Animationen (nur über useCurrentFrame, keine CSS-Transitions). Lies die aktuelle Remotion-Dokumentation zu @remotion/renderer, bevor du das einbaust.
5. Seite /pipeline/[id]/studio: Status live (Polling genügt), Vorschau-Player mit signierter URL, "Freigeben" setzt das content_item auf 'fertig', "Verwerfen" auf 'verworfen'.

AKZEPTANZKRITERIEN
- Ein Auftrag aus dem Dashboard wird vom Worker abgeholt und in eine abspielbare 9:16-MP4 gerendert.
- Der Worker funktioniert ohne einen einzigen Datenbank-Key in seiner Umgebung.
- Falsches oder fehlendes Token: die Routen antworten mit 401 (Kontrollprobe mit einem Fantasie-Token).
- Ein absichtlich kaputter Auftrag landet auf 'fehler' mit lesbarer Meldung, der Worker läuft weiter.
- Zwei Worker holen nie denselben Job.
- npm run build und npm run lint laufen durch, kein Key im Repo.

REGELN
Zeige mir zuerst die Routen und das Datenmodell und warte auf mein OK. Migration spiele ich selbst ein. Kein any.