video-talkcraft

video-talkcraft — Erklärvideo-Skill

Drei Hauptquellen vereint: Pipeline (Sprache → Wort-Zeitstempel → Remotion) + Vokabular (108 Animationsrezeptkarten mit abspielbaren Demos + selbstständigem TSX) + Kameraführung (7-stufiges Anti-PowerPoint-System) + Visuelle Sprache (Apple-Standard).

Kernparadigma: Der Erzähltext treibt die Bilder an. Jeder Satz muss eine lebendige visuelle Antwort erhalten (extrem langsame Kamerafahrt / Veränderung vorhandener Elemente). Aber neue Elemente treten nur an semantischen Satzgrenzen auf, das mechanische "ein neues Element pro Satz" ist verboten (ein Element pro Satz ist die Wurzel von überladener Unordnung; Schnitte folgen semantischen Absätzen, Layout-Budget siehe cinematography.md §4.5); Ein Takt hat nur einen Protagonisten, der dann Platz macht; Untertitel-Satzgrenzen = Zeitanker des gesamten Clips.

Ablauf

① Skript → ② Spracheingabe + Zeitstempel (lokale CPU) → ③ Material → ④ SHOTBOOK-Layer-Matrix → ⑤ Implementierung (Globalsystem → Erste Szene zuerst machen + bestätigen → Restliche Szenen)
                                → ⑥ Rendern → ⑦ Dreifache Abnahme (Maschinentests bestanden + 1 Review für P0/P1) → ⑧ Lieferung (optional ≤3 weitere Reviews)

⓪ Start-Check: Einheitliche Abhängigkeiten + Bildformat & visuelle Sprache

Es gibt nur eine Abhängigkeit: Alle remotion/node_modules und workbench/node_modules von Erklärprojekten sind symbolische Links auf <SkillRoot>/runtime/node_modules, die Version wird nur in runtime/package.json festgelegt (alle @remotion/* Pakete mit derselben Version). Erste Aktion bei einem neuen Projekt (Benutzerentscheidung vom 2026-09-15: Vor jedem neuen Video auf Updates prüfen):

bash <SkillRoot>/runtime/check-runtime.sh --upgrade   # Installiert gemeinsame Abhängigkeiten + freigegebenen Headless-Browser + verlinkt Workbench; wenn Remotion eine neue Version hat, wird ein全家升级 durchgeführt und 1 Frame gerendert, bei Fehler automatischer Rollback

Wenn die letzte Zeile [runtime] OK lautet, kann es weitergehen; nach einem Upgrade müssen die Änderungen an runtime/package.json / package-lock.json committet werden. Keine Upgrades während der Produktion (Der Zwischenspeicher für Segment-Master erkennt keine Abhängigkeitsversionen; gemischte Versionen führen zu inkonsistenten Segmenten). Im Projektverzeichnis wird niemals npm install ausgeführt (würde in das gemeinsame Verzeichnis schreiben); zum Hinzufügen eines Pakets → in runtime/package.json einfügen, npm ci ausführen und committen.

Bildformat & visuelle Sprache (Vor dem Start festlegen, gesamten Ablauf referenzieren)

• Bildstandard: Querformat 1920×1080 (Benutzerpräferenz); nur bei explizitem Wunsch für Douyin/Hochformat-Kanäle 1080×1920
• Visuelle Sprache: Wenn der Benutzer einen Stil angibt, wird dieser verwendet (gesamte Token-Substitution); wenn nicht, wird zuerst aus dem Skript der Bereich abgeleitet und darauf basierend ein Stilprofil erstellt (references/design-language.md §0: Lies das ganze Skript, beantworte "Worüber wird gesprochen? / Für wen? / Welcher Ton?" → Bereich → Stilprofil-Tabelle gibt: Grundfarbstrategie / Akzent / Schriftcharakter / Material & Kartenform / Diagrammsprache / Materialstimmung / Energie-Level, Schreibe in SHOTBOOK §0 G0 Stilprofil), das Grundgerüst bleibt Apple-Standard (eine Akzentfarbe / ein Schlagschatten / Grundfarbwechsel nach Szenen / zwei Schriftgewichte / Standard-Szenenhintergrund: Hell pastel-mesh-flow / Dunkel mesh-flow-dark – 12 Hintergründe in §1.1, Code template/motion-systems/backdrop.tsx), das abgeleitete Stilprofil wird in theme.ts gespeichert. Für jeden Stil gilt nur eine Regel: Kein spontanes Farbnehmen pro Szene. Karten sind neutrales UI, müssen im Clip angepasst werden: Die Demos / TSX von Animationskarten sind stilneutral; nach dem Kopieren in das Projekt wird das Erscheinungsbild gemäß Stilprofil geändert (Farben / Schrift / Rundung / Material / Diagrammachsen & Marker / Platzhalter), die Bewegungslogik bleibt unverändert (Timing / Easing / geometrische Proportionen / Ebenen), Verträge & Gegenbeispiele siehe design-language §0.4; SHOTBOOK schreibt für jede Szene eine Anpassungszeile

① Skript

• Jeder Satz ein Informationspunkt, Haken im ersten Satz (Zahlen / Konflikt); 13 Sätze ≈ 95s
• Zahlen immer in chinesischen Schriftzeichen (Zeitstempel werden zeichengenau verankert, 197747 kann nicht mit der Aussprache von "neunzehn siebentausend" abgeglichen werden); englische Markenwörter direkt geschrieben (chinesisch-englische Mischung bereits verifiziert)
• Zuerst recherchieren und Fakten überprüfen, eine "faktische rote Linien-Liste" erstellen (Zahlen, die nicht falsch sein dürfen / nicht verifizierte Daten nicht referenzieren)

② Spracheingabe → Vorschnitt → Wort-Zeitstempel (Standard: lokale CPU; optional Fish Audio)

Standardmäßig wird eine fertige Audiospur verwendet: Echte Aufnahme oder jedes TTS, Eingabe = eine vollständige Audiospur (wav/mp3) + das dazugehörige, zeichengenaue Skript. Wenn keine Aufnahme vorhanden ist und der Benutzer eine Synthese wünscht, kann untenstehende Option B verwendet werden; sie ersetzt keine vorhandene Aufnahme oder den standardmäßigen lokalen CPU-Prozess.

②-0 Vorschnitt der Sprache (bei echten Aufnahmen Pflicht; bei TTS nur Atempausen entfernen, kann übersprungen werden) – Füllwörter (嗯 / 呃 / 那个…), Stotter-Wiederholungen, zu lange Pausen ausschneiden, Vor der Zeitstempelberechnung durchführen (Nach der Zeitstempelberechnung das Audio zu bearbeiten würde das Timing / die Beats vollständig verschieben; Vorschnitt → Zeitstempel → alles Weitere, Reihenfolge unveränderbar):

python3 scripts/voice_trim.py audio/raw.wav script.json --dry-run --words-out audio/asr_words.json   # Zuerst nur einen Bericht erstellen: Liste der [Füller / Wiederholungen / Pausen] mit Start/Ende + Gesamtschnittmenge; ASR-Ergebnisse speichern
python3 scripts/voice_trim.py audio/raw.wav script.json --words audio/asr_words.json --out audio/full.wav \
    [--video dh/host_raw.mp4 --video-out dh/host.mp4]               # Nach Bestätigung durch Benutzer speichern (verwendet die Wortliste aus vorherigem Schritt, keine erneute ASR); das zugehörige Videomaterial wird mit derselben EDL geschnitten (Audio und Video Frame-genau gleich lang)

• Das Skript ist die Wahrheit, lieber auslassen als falsch schneiden: Es werden nur Einschübe im ASR entfernt, die nicht im Skript stehen – die vollständig aus Füllworttabellen bestehen (Füller), oder die Stotter-/Wiederholungen sind, die direkt an den Skripttext grenzen (repeat); ASR-Fehler (falsch erkannte Zeichen aus dem Skript) werden niemals geschnitten (sonst wird die tatsächliche Aussprache dieses Zeichens entfernt); Wiederholungen außerhalb des Skripts werden nur gemeldet, --cut-unmatched schneidet sie. Standardmäßig wird FireRed als Wortquellen-Engine verwendet (gleicher Backend wie die Zeitstempel unten), es können auch zeichengenaue SRT-Dateien aus剪映 etc. eingelesen werden (--srt) oder JSON auf Wortebene (--words); Satzebene-SRT kann Füllwörter nicht lokalisieren, das Skript gibt eine Warnung aus. Ohne Skript werden nur Füllwörter geschnitten, deren gesamter Token-Text exakt der konservativen Wortliste (嗯 / 呃 / 额 / um…) entspricht – exakter Textvergleich, keine Lautähnlichkeit (五≠唔, 饿≠呃); Kurze, benachbarte wiederholte Wörter werden ohne Skript nur gemeldet, nicht geschnitten (auf Zeichenebene kann man Reduplikation nicht von Stottern unterscheiden). Beim Schneiden einer transparenten Webm-Aufnahme wird ein Frame auf Alpha geprüft; wenn die Framerate stimmt, aber Transparenz verloren geht, gilt das als FAIL.
• Pausen: ≥0.7s Stille auf 0.35s reduzieren (den leisesten Fenster-Raumklang innerhalb des Segments beibehalten, keine digitale Null einfügen), Ein- und Auslauf 0.25 / 0.5s; Schnittpunkte zuerst auf Energie-Täler setzen, dann auf das 30fps-Frame-Raster ausrichten; cuts.json ist die EDL (enthält die Quell-→Neue-Zeitachse-Mapping-Tabelle, die für den Videoschnitt und alle nachfolgenden Abgleiche verwendet wird).
• Der Dry-Run-Bericht muss dem Benutzer zur Ansicht vorgelegt werden, bevor er gespeichert wird: Einträge mit der Markierung "Schnittpunkt liegt nicht in einer Stille, bitte anhören" werden dem Benutzer zum Anhören jener Stelle vorgelegt; das Skript löscht nur, synthetisiert nicht, ändert nicht die Geschwindigkeit oder die Tonhöhe. Nach dem Schneiden des Videomaterials wird der Check aus ③ (preflight.py --media-only) ausgeführt, um die Länge zu überprüfen – dieselbe EDL gilt nur für dieselbe Aufnahme.

Wort-Zeitstempel (für das vorbereitete audio/full.wav):

# Option A (vorhandene Aufnahme, lokale CPU-Alignment):
pip install zhconv pypinyin sherpa-onnx soundfile numpy   # Alle Abhängigkeiten für das Standard-Backend FireRedASR2-CTC int8
# Erstmalig: Modell herunterladen 767MB (model.int8.onnx + tokens.txt) nach ~/.cache/koubo/<Modellname>/ ablegen, Link siehe Kommentar am Skriptkopf
python3 scripts/timestamps_cpu.py audio/full.wav script.json audio/timestamps.json
# Alternative (ohne manuellen Modell-Download): pip install faster-whisper und dann `--backend whisper` hinzufügen (erster Lauf lädt 460MB automatisch herunter)
python3 scripts/make_timing.py audio/timestamps.json remotion/src/timing.json

# Option B (optional: Sprachsynthese + Zeitstempel generieren, Standard-Anfrage an s2.1-pro-free; Verfügbarkeit abhängig von Fish Audio):
pip install requests python-dotenv   # Erfordert auch ffmpeg, wird vor der Generierung geprüft
# In .env FISH_AUDIO_API_KEY=xxx und optional FISH_AUDIO_REFERENCE_ID=xxx konfigurieren (siehe .env.example)
python3 scripts/tts_fishaudio.py script.json audio/full.wav audio/timestamps.json --timing-out remotion/src/timing.json

• tts_fishaudio.py: Standardmäßig --mode sentence, eine Anfrage pro Satz, fügt die durch --pause-sec angegebene echte Stille ein (Standard 0.25 Sekunden); --mode stream eine Anfrage für das ganze Skript, behält natürliche Pausen bei. Beide empfangen UTF-8 SSE, schreiben die Datei erst nach Abschluss der Generierung, kein Streaming. Zuerst PCM dekodieren, dann zusammensetzen, Offset basierend auf Sample-Zahl. Bei leerem Audio, fehlender/ungültiger Ausrichtung oder Textinkonsistenz wird ein Fehler gemeldet; ignoriert nur Satzzeichen, Groß-/Kleinschreibung und Zeichenbreite, konvertiert Zahlen nicht automatisch. Chinesisch verwendet die zeichengenaue Ausrichtung der API, englische Wörter werden interpoliert; match/ok bestätigt nur die Textzuordnung, ein Probehören ist dennoch erforderlich. Wenn nach der Synthese ein Vorschnitt durchgeführt wird, muss das CPU-Alignment erneut ausgeführt werden.
• timestamps_cpu.py: ASR-Wort-Zeitstempel → zeichengenaue Ausrichtung mit dem Skript (CJK sind zuverlässige Anker, Matching-Key = vereinfacht/traditionell vereinheitlicht + Pinyin ohne Töne; Homophone gelten nicht als Fehler; lateinische Wörter werden von ASR oft falsch geschrieben, Interpolation zwischen den Ankern) → Jeder Satz wird auf match geprüft, <0.90 wird zur manuellen Überprüfung markiert. Standard-Backend: FireRedASR2-CTC (am stabilsten am Ende, keine Fehlalarme; Ganzer Input >~200s kann crashen, Speicher quadratisch wachsend; Skript teilt standardmäßig an Stille in ≤75s Segmente und addiert Offset, --chunk-sec konfigurierbar), Alternative: faster-whisper; Benchmark-Daten und Modell-Download-Links für alle Backends siehe Kommentar am Skriptkopf.
• timestamps.json Schema: {sr, total, sentences:[{i,text,start,end,match,ok,words:[{text,start,end}]}]} – words sind CJK Zeichen + lateinische Token (Satzzeichen übersprungen); jedes Ausrichtungswerkzeug, das dieses Schema erfüllt, kann ersetzt werden.
• make_timing.py: Konvertiert in timing.json (Zeichen 1:1 mit Text, Satzzeichen haben Dauer 0), wird für tSay/msSay Ankerabfragen verwendet
• Selbstkontrolle der Audiospur (Hören): Keine Übersteuerung/Abschneiden/Fehlaussprache; ~0.3s Atempause zwischen Sätzen lassen, Zeitanker sind dann stabiler

②-1 Semantische Annotation (ab 2026-09-22 Pflicht, Hauptdokument references/semantic-annotation.md)

Jeder Satz des Skripts wird annotiert mit "Was macht dieser Satz?", gespeichert als semantics.json im Projektstamm – dies ist das Bedarfsprodukt für die Kartenauswahl, ohne sie bleibt nur der Eingabetyp als Filter, der Rest der 80+ Karten wird aus dem Gedächtnis ausgewählt (Der Clip "我是万里" vom 2026-09-21 hat so die energieärmste Textkarte aus dem gesamten Pool bekommen, während die P0-Personennamen-Karte niemand gefunden hat).

python3 <SkillRoot>/scripts/semantic_annotate.py --init     # Erzeugt ein Grundgerüst aus timestamps.json (mit lexikalischen Hinweisen `hint`)
#   Pro Satz `sem` (26 geschlossener Wortschatz, siehe taxonomy.md „Semantischer Index“) / `weight` (main Hauptsatz = erlaubt neue Elemente, sub Nebensatz) / `entities` / `need` ausfüllen
python3 <SkillRoot>/scripts/semantic_annotate.py --stats    # Validierung: Zeichengenau mit Zeitstempel · Geschlossener Wortschatz · Lexikalische Hartregeln (我是X→Selbstvorstellung, 点赞订阅→Aufruf, 数量词→Daten) · Jede Szene mindestens ein main

Die Annotation ist ein Derivat: Vorschnitt → Zeitstempel → Annotation → alles Weitere; wenn das Skript geändert oder neu geschnitten wird und der text nicht mehr übereinstimmt, ist die Annotation ungültig und muss mit --init neu erstellt werden. ②-1 ist vor dem Storyboard, daher ist das shot-Feld zu diesem Zeitpunkt leer (SHOTBOOK noch nicht geschrieben): Nach ④ muss es einmal zurückgefüllt werden, sonst kann die szenerübergreifende Prüfung nichts finden.

python3 <SkillRoot>/scripts/semantic_annotate.py --sync-shots   # Nach ④: Basierend auf Start/Ende-Sekunden des SHOTBOOK-Titels (oder shots.json) die `shot`-Felder zurückfüllen, nur `shot` wird geändert, Annotation bleibt erhalten

③ Material

• Die Materialliste wird aus der semantischen Annotation von ②-1 generiert, nicht durch Raten: Sätze mit need = evidence werden reale Seiten/screenshots / Quellenangaben benötigt, identity benötigt Headshots und Konto-Informationen, quantify benötigt Diagramme oder Datenquellen, und die in entities genannten Personen / Marken / Orte / URLs sind die Suchbegriffe.
• Zuerst für jede Szene den Materialmodus festlegen (Mehrfachauswahl, kombinierbar): B-roll (echtes Video) / Bild (Foto / Poster / Illustration) / Screenshot (Webseite / Interface-Beweisbild) / reine Animation – z.B. "B-roll als Hintergrund + Screenshot-Beweiskarte". Für Nachrichten/Informationsthemen haben Beweise Priorität: Playwright-Live-Screenshots sind informativer als generische B-roll. Die vier Stufen entsprechen den Taxonomie-Eingabetypen V / 图 / 截图 / 文, SHOTBOOK schreibt pro Szene eine Zeile Material: V (Pfad) · 图 (Pfad) · 文 (Format siehe ④)
• Echtes Videomaterial ist Pflicht, nicht optional (harte Regel vom 2026-09-06): Null B-roll/Bildmaterial im gesamten Clip = nur Animation + Sprecher, das Publikum sieht "PowerPoint-Vortrag". preflight.py prüft das SHOTBOOK: Null V / 图 Szenen werden direkt FAIL, der Anteil an V / 图 Szenen < 1/3 gibt WARN (muss im SHOTBOOK begründet werden, z.B. Beweisthemen mit hauptsächlich Screenshots). "Dieser Clip verwendet kein B-roll" ist nicht als Designentscheidung erlaubt; wenn keine Videoquelle gefunden wird, auf Bilder herabstufen (Pexels Fotos Original → Pixabay), erst wenn auch keine Bilder vorhanden sind, in "Unvollständig / Nicht gesammelte Liste" eintragen. Bilder und Videos mit gleichem Key, Sammelspezifikationen (Auflösungsminimum, Zielordner, Registrierung) siehe references/broll-sources.md „Bildsammlung“
• Harte Regel für echte Bilder: Wenn es für das Thema eine echte, abrufbare Webseite gibt (Produktseite/GitHub/Dokumentation/Galerie), dann ist es verboten, Browser/Seiten-artige Szenen im Clip mit animierten Mockups als Screenshot-Ersatz darzustellen – die grauen Balken in den Kartendemos sind Platzhalter, sie müssen im Clip gemäß der "Wiederverwendungshinweise" der Karte durch ein <img> mit echtem Bild ersetzt werden; Mockups sind nur erlaubt, um schematische UIs darzustellen, für die es kein reales Gegenstück gibt, und jede Szene muss im SHOTBOOK annotiert werden mit "Warum kein echtes Bild". Daraus abgeleitet: Wenn der Sprecher "so einen Clip / Effekt" beschreibt, muss das Beispiel ein echter Clip-Ausschnitt sein (<OffthreadVideo> eingebettetes eignes Material/eigenes echtes Video, gemutet); wenn "lange Seite / Dashboard / Parameter-Seite" beschrieben wird, verwende Playwright vollständige Seiten-Screenshots (Vergrößerungsglas-/Rundflug-Animationen koordinaten direkt auf dem echten Bild anwenden). Alle Markierungen auf echten Bildern müssen maschinell gemessen werden, niemals per Augenmaß: Seitenelemente mit DOM getBoundingClientRect, das Bild selbst pixelgenau messen (Augenmaß mit ±30px Abweichung rahmt das falsche Element ein); Wenn das echte Bild scrollt oder sich bewegt, müssen Markierungen (Kreis/Rahmen/Pill) im Koordinatensystem des Inhalts fixiert sein und sich mitbewegen, Fixierung auf Bildschirmpositionen ist die Wurzel von Fehlausrichtungen.
• Einzel-Video-Szenen benötigen einen thematischen Rahmen (Benutzerentscheidung vom 2026-09-07): Wenn das einzige Element einer Szene ein Video ist (Bildschirmaufzeichnung / einzelnes B-roll / zitierter Clip oder Interview), darf es nicht nackt, vollflächig oder auf weißem Hintergrund ohne Rahmen platziert werden; auch kein vorgetäuschter Player (keine Fortschrittsleiste, kein Play-Button, keine Timecodes – das wäre eine Lüge, da es kein echter Player ist). Der Videobereich muss mit einer template/components/theme-frame.tsx <ThemeFrame kind> umgeben sein: Acht Stile (Retro-Browser-Fenster / Zeitschriftenrahmen / 35mm-Film / Polaroid / Blaupause / Notizbuch / Briefmarken-Zackenrand / doppelter Haarstrich), Ein Stil pro Clip, abgestimmt auf die Stimmung, und im SHOTBOOK in der Anpassungszeile notieren; bei Multi-Video-Karten (bed-echo-blur Vordergrund / split-60-40-story linke Zelle / gallery-wall-dolly) wird der Videobereich ebenfalls mit demselben Stil umgeben. Der Rahmen kümmert sich nur um die Form und seine eigene dekorative Funktion, der gesamte Ein-/Ausgang / die extrem langsame Kamerafahrt gehört zur Kameraführungsebene; das Bild im Rahmen wird nicht bearbeitet (kein Filter / keine Skalierung / kein Fade). Ausnahmen gibt es nur zwei: Video als Hintergrund (bed-echo-blur / §1.2 Echtes Video-Hintergrund), sowie Produkt-Interface-Karten (chat-gpt / claude-code Typ, bei denen das Interface der Inhalt ist). Standbilder bekommen keinen Rahmen (der Rahmen sagt "das ist eine Videoaufnahme", was bei einem unbewegten Bild wie eine Lüge aussieht; Standbilder verwenden media-pop-in / slow-push-in). Regeln & Acht-Stile-Tabelle: design-language §1.3
• Webseiten werden nicht als Standbilder eingefügt: Bei der Recherche/Materialsammlung gefundene nutzbare Webseiten, dürfen im Clip nicht als statischer Screenshot eingefügt werden, sondern müssen wie eine Handkamera „gefilmt“ werden – Scrollen (evidence-scroll-tour◆: gleichmäßiges Hochscrollen ≈10% Seitenhöhe/s, bei Schlüsselbegriffen vorzeitig verlangsamen und 1~2s anhalten) / Rundgang (stage-keyframe-tour◇: Lange Seite liegt auf Bühne, Kamera stoppt an Interessenspunkten) / Vergrößern (magnifier-detail runde Lupe kurz anschauen und weg, pip-zoom-box◈ langfristig anzeigen) / Markieren (highlighter-sweep ganze Zeile überstreichen, ink-underline◇ ein Wort unterstreichen, scribble-annotation Kreise/Pfeile, corner-bracket-frame◈ Bereich einrahmen); eine Seite, die auf einen Bildschirm passt, bekommt mindestens slow-push-in als Grundrauschen. Eine Szene, eine Methode: Im Scroll-/Rundgang-Segment erscheint keine Lupe und es wird nicht live gezeichnet; die Reihenfolge ist „Scrollen zu → Anhalten → Markieren/Vergrößern → Weiter scrollen“; Beschreibungen finden sich in shot-design.md §2④ „Webseiten-Filmen". Das Material wird gemäß broll-sources.md „Webseitenfilm-Material-Sammelspezifikationen“ abgelegt: Playwright vollständiger Seiten-Screenshot in 2× Auflösung + JSON mit den tatsächlichen DOM-Koordinaten der Ziele aus derselben Sitzung (Vergrößerungsglas / Markierungen / Stopps verwenden alle diese Koordinaten, gemäß der obigen Regel „Verbot von Augenmaß“). Das „Filmen“ erfolgt komplett durch Remotion auf dem langen Screenshot (seek-sicher, Wortanker-konform); kein Browser-Screenrecording (Frame-Rate instabil, Lazy-Loading und fixierte Header stören, nicht mit Wort-Zeitstempeln synchronisierbar). Einzige Ausnahme: Kleine Screenshots, die auf einen Bildschirm passen und nur als Beiwerk dienen (eines von mehreren in einem media-pop-in), können statisch in eine Karte eingefügt werden, müssen aber trotzdem Ken Burns haben und dürfen nicht das Hauptmotiv sein.
• Für Szenen, die mit B-roll markiert sind, 2–3 englische visuelle Konzeptwörter auflisten und Pexels + Pixabay API parallele Suche durchführen, Kandidaten in assets/broll/ speichern; Quellhierarchie und Lizenzgrenzen (Nur quellenfreie Materialien verwenden) siehe references/broll-sources.md
• Recherche-Buchhaltung: Jede Quellseite, die eine Schlüssel-Fakt enthält, wird einzeln als Screenshot archiviert, in sources.md werden Link und lokaler Screenshot eins-zu-eins zugeordnet (nur Link speichern ohne Beweis ist verboten); im Clip werden bevorzugt archivierte Screenshots als Bildbeweis verwendet + Mikro-Quellenzeile
• Wenn B-roll/Screenshots + das dazugehörige Sprechermaterial (Aufnahme / fertiger Digital-Human) vorhanden sind, wird der Sprecher immer zu einem permanenten, kleinen Element herabgestuft – runder Kopf-Chip (host-shrink-to-chip◆) oder ausgestanzte Person in die Ecke, platziert in der unteren linken/rechten Ecke; Sprecher nicht wegschneiden, Sprecher nicht das gesamte Bild einnehmen lassen. Die zwei Optionen und alle harten Constraints sind in references/host-footage.md §5 festgelegt, Kameravoreinstellungen in shot-design.md §2⑦
• Manim-Diagramme: Nach --transparent --format=mov unbedingt in VP9 webm konvertieren (-c:v libvpx-vp9 -pix_fmt yuva420p)
• Alles in public/ ablegen, kein Laden von entfernten Quellen während des Renderns verboten
• ③ Abschluss: Material-Check muss durchgeführt werden (die harten Regeln aus host-footage / broll-sources in Assertionen umwandeln; die Antwort war längst in den Referenzen, aber niemand hat zur richtigen Zeit nachgesehen, das war der gemeinsame Fehlermodus der zwei größten Fallstricke aus dem 2026-09-06 Review – also keine Dokumentation mehr hinzufügen, sondern vor dem Start prüfen):

python3 scripts/preflight.py --media-only --host remotion/public/dh/host.webm --fps 30 --voice audio/full.wav
# Prüft: Personenvideo r/avg Framerate konsistent (VFR) · Quellvideo keine doppelten Frame-Signaturen · Material fps = Clip fps (wenn unterschiedlich → Clip fps auf Material fps ändern, verboten mit -r direkt zu konvertieren) ·
#     Länge mit Aufnahme Frame-genau · Tatsächliches Seitenverhältnis · Materialbestand (Anzahl Video/Bild/Webseiten-Screenshots) · sources.md registriert. Wenn ein FAIL, dann nicht zu ④ gehen.

④ SHOTBOOK (Muss erstellt werden, vor Implementierung überprüfen)

Zuerst mit references/shot-design.md für jede Szene das Drei-Ebenen-Schicht-Arbeitsblatt ausfüllen (Hintergrundebene/Hauptebene/Text-Ebene + jede Ebenen-Animation

• sieben Kameratyp-Voreinstellungen), dann nach references/cinematography.md §4 in eine Layer-Matrix umwandeln, Beispiel references/shotbook-example.md. Jede Szene: Eine Absichtserklärung + Protagonisten-Übergabelinie + schrittweise Layer-Matrix (Schritte verankert an Wort-Zeitstempeln; jede Aktion muss beantworten können "Zu wem gehört die Bewegung?"). Jede Szene muss eine Material:-Zeile enthalten (maschinenlesbar, preflight prüft jede Datei einzeln): - Material: V (public/broll/gpu.mp4) · 图 (public/stills/a.jpg, public/stills/b.jpg) · 截图 (public/pages/gh/page.png) · 文 – V / 图 / 截图 müssen Pfade in Klammern haben, "待采" (noch zu sammeln) = FAIL; reine Animationsszenen schreiben Material: 文. Pflichtabschnitt „## Unvollständig / Nicht gesammelte Liste": Jedes "Dieser Clip macht kein X" muss eine von zwei Optionen sein – entweder in §0 als Designentscheidung kategorisiert (+ Begründung), oder in diesem Abschnitt (+ Blockierungsgrund + ob Fallback-Quelle getestet wurde); "Keine" ist erlaubt, den Abschnitt wegzulassen ist verboten. Dieser Abschnitt fängt speziell ab: „Unvollständigkeit wird als Designprinzip verkleidet, was dann zu einer nicht mehr hinterfragten Prämisse wird“ (Der eigentliche Fehlermodus des 2026-09-06 Reviews). G0 schreibt eine Zeile „Modellszene: sNN" (für ⑤-1 zuerst machen und bestätigen): Standard s01; wenn s01 eine Kapitelkarte / leere Szene ohne Hauptelement-Animation ist, wähle die erste Szene mit einer Karte, Untertiteln, einer Person oder Material. Schritte müssen maschinell überprüfbar sein: Jeder visuelle Akzent wird in remotion/beats.json geschrieben ({t, anchor, sentence, what}, t wird immer über timing.json/atChar() ermittelt, Eingabe von ungefähren Sekundenzahlen per Hand verboten – solche Ungenauigkeiten werden vom Standbild-QA nicht erkannt), die SHOTBOOK-Takt-Tabelle muss mit beats.json übereinstimmen, Maschinenprüfung mit scripts/beat_lint.py gegen timestamps.json Validierung |Δ|≤0.1s. Nicht im Takt, nicht sichtbar: Zahlen/Grafiken, deren Wortanker noch nicht erreicht ist, müssen vollständig unsichtbar sein (opacity 0), verboten, sie abgedunkelt/ausgegraut „voranzukündigen“; Inline-Zahlen müssen zusammen mit den ihnen folgenden Zeichen ausgeblendet werden (ein leeres Feld wie „就 __ 类“ ist ebenfalls ein Makel). Szene nicht leer starten: Wenn das Zeitfenster vom Szenenbeginn bis zum ersten Animationsanker >1.5s ist, muss es eine tragende Szene geben (echtes B-roll / Fortsetzung eines Elements aus der vorherigen Szene / echte Materialwand), keine leere Leinwand, die auf den Wortanker wartet. Szenenende-Schutz: Wenn der Animationsanker-Einfallspunkt <0.7s vom Szenenende entfernt ist, entweder vorziehen oder in die nächste Szene verschieben – der Punkt wird vom Übergang geschluckt; beat_lint.py --shots shots.json prüft maschinell die harte Untergrenze von ≥0.5s. Übergangsereignisse auf Szenenebene kommen ebenfalls in beats.json: Der Abdeckungspeaker-Zeitpunkt von Shape-Wipe/Szenenwechsel wird ebenfalls von einem Wortanker generiert und in die Tabelle eingefügt – Eine Übergangsereignistabelle mit per Hand eingegebenen absoluten Sekunden schwebt außerhalb des maschinell überprüfbaren Systems, das Standbild-QA und beat_lint sehen sie nicht. Layout-Budget (vollständige Tabelle in cinematography.md §4.5): Storyboard nach semantischen Absätzen schneiden, jede Szene eine primäre visuelle Aufgabe; Reine Text-Szenen müssen mit Begleitgrafiken ausgestattet werden (Benutzerfeedback vom 2026-09-07: "Nur Textanimationen sind zu eintönig"): Szenen, deren Materialzeile nur „文" enthält (außer Kapitelkarten), müssen in der Layer-Matrix eine zusätzliche Zeile haben „G5 Schemazeichnung ← Spricht über X, daher zeichne Y" (references/schematic.md, Code template/motion-systems/schematic.tsx), Preflight gibt eine WARN für fehlende Zeilen bei reinen Text-Szenen; Die Animation von Schlüsselsätzen („Aber diesmal nicht X"-artige Wendungen/Fragen) gehört zur darauffolgenden Szene, die sie einleitet; zu jedem Zeitpunkt auf dem Bildschirm sind ≤3 Hauptelemente (abgewertete, bleibende Elemente werden mitgezählt), jede Szene hat mindestens einen leeren Quadranten; Hero-Layout eins pro Bildschirm. Layout-Richtlinie (vollständige Tabelle references/layout.md): Budget verwaltet "Wie viel", Richtlinie verwaltet "Wo platzieren, wie groß, wie ausrichten" – SHOTBOOK schreibt für jede Szene eine Layout-Zeile (Spaltenbreite + Gruppe-Umgebungsbox + Ausrichtungsbasis + Schrift-Grad), Overlay-Frame mit debugOverlay zur Überprüfung der neun Punkte, ein FAIL = P1; Einzelner Satz-Hero zentriert, darf aber kein Gesicht überdecken (inkl. Gesichter im B-roll, vertikal auf Drittel-Regel außerhalb des Gesichts ausweichen). Layout-Rotation (Benutzer vom 2026-09-21: Der Clip "Person unten links, Material im mittleren Quadrat, rechts Text, zu starr"; vollständige Tabelle in cinematography.md §4.5 Punkt 9): Vor dem Schreiben der Matrix pro Szene, schreibe in G0 eine „Layout-Rhythmus-Tabelle" (| Szene | Person-Form·Position | Material-Container | Hauptkarte |, Format in cinematography.md §4) – Dieselbe Präsentationskarte (Material-Präsentation / Daten / Kamerafahrt-Typ) nicht 3 Szenen hintereinander verwenden, insgesamt ≤1/3 des Clips (bei ≥6 Szenen); Personenform (Halbkörper / Chip unten links / Chip unten rechts / Split-Screen-Zelle / Ausgestanzte Person / Kurzzeitiges Verschwinden) und Materialcontainer (Vollformat-Ausblutung / Gerahmt / Split-Screen-Zelle / Hintergrund / Mehrfachbild-Layout / 3D-Wand / Lange Seite) nach 3 aufeinanderfolgenden Szenen mindestens eines wechseln; dasselbe B-roll nicht in zwei benachbarten Szenen. Einzelnes B-roll nach den sieben Stilen von shot-design.md §2⑦ auswählen, benachbarte Szenen unterschiedlicher Stil, Mehrfachmaterial nach der Beziehungstabelle von §2④′; Preflight prüft nach Rhythmus-Tabelle + Anpassungszeile (Wiederholung / Anteil FAIL). Rotation bedeutet Wechsel des Layouts, nicht Hinzufügen von Bewegung – in jedem Stil gibt es nur extrem langsame Kamera-Fahrten. Jede Szene muss eine „Kartenauswahlzeile" enthalten (②-1 Semantik → Karte; Kandidaten maschinell bereitgestellt):

python3 <SkillRoot>/scripts/card_match.py --out qa/card-candidates.md   # Semantik × Materialzeile × Kartenindex → Jede Hauptsatz-Semantik pro Szene erhält passende Kandidaten + Sortiergrund + Ablehnungsgrund

Vor dem Ausführen semantic_annotate.py --sync-shots ausführen, um shot zurückzufüllen (in ②-1 gab es noch kein Storyboard). Die Kandidatentabelle listet nicht nur Kandidaten nach Semantik, sondern auch eine separate Zeile für Szenen, die Material deklariert haben: Material-Aufnahme-Kandidaten – Wenn V / 图 / 截图 deklariert ist, aber keine Präsentations-/Kamerafahrt-Karte zur Aufnahme vorhanden ist = nacktes Material, Preflight gibt FAIL. SHOTBOOK schreibt pro Szene - Kartenauswahlzeile: <Semantik> → <Karte>, <Semantik> → <Karte> (Die Karten in der Auswahlzeile müssen tatsächlich in die Anpassungszeile übernommen werden, Preflight prüft das); Wenn eine Karte außerhalb der Kandidatenliste gewählt wird, muss in der Szene eine Zeile geschrieben werden: - Semantik-Abweichung: Selbstvorstellung ← Eröffnung hat bereits die Identität genannt, s11 wiederholt sich nicht (Begründung ≥4 Zeichen, Preflight akzeptiert diese Zeile als Freigabe). Die Schritt-Liste der Layer-Matrix bekommt eine zusätzliche Spalte Semantik (Werte aus semantics.json, keine neuen Wörter erfinden), sodass „was dieser Schritt macht" im Storyboard maschinenlesbar ist. Kartenauswahl muss Karten-Erfahrung lesen: Für jede ausgewählte Karte die Abschnitte „Bekannte Fallstricke" und „Selbstcheck nach Einfügen" aus references/cards/<slug>.md Zeile für Zeile in die Selbstcheck-Spalte der Layer-Matrix dieser Szene kopieren, nach der Implementierung Punkt für Punkt prüfen (z.B. Anschnitt/Rahmen/Unterstreichungs-Karten: muss prüfen, ob die Markierung das Ziel umschließt; gooey-morph nur für Bilder, nicht für Text, und ohne Person zentrieren; chapter-title-card Jedes Kapitel bekommt ein eigenes Farbschema + ein zum Kapitelinhalt passendes Strichmännchen-Motiv, SHOTBOOK schreibt die Kapitelthemenzeile – vier Kapitelkarten mit derselben Farbe und demselben Muster fühlt sich an wie "schon wieder", nicht wie "umblättern") – Karten-Erfahrung, die nicht ins SHOTBOOK einfließt, ist gleichbedeutend mit nicht gelesen. Animationsvokabular wird aus den 108 Rezeptkarten ausgewählt, beide Filter durchlaufen den maschinell generierten Index aus references/taxonomy.md (Quelle sind die fünf Felder des Frontmatters jeder Karte: „Eingabe / Semantik / Materialform / Position / props", scripts/cards_index.py --write erzeugt, --check validiert, manuelle Indexänderungen sind ungültig): Zuerst nach dem Eingabetyp dieser Szene filtern (Person / V / 图 / 截图 / 文 / 界 / 场 – „Eingabetyp-Index"), dann nach der Semantik dieses Satzes filtern (Selbstvorstellung / Daten / Vergleich / Aufzählung / Zitat / Aufruf … 26 geschlossener Wortschatz – „Semantischer Index", eine Karte wird nur unter der Semantik gelistet, für die sie speziell konzipiert ist); Karten mit ◦ im Index haben kein props mit austauschbarem Inhalt (exponieren nur Ressourcen/Skins oder nichts), um Text/Daten zu ändern muss das TSX geändert werden (in der Wiederverwendungszeile jeder Karte steht, was an den props geändert werden kann). Die 29 neuen Karten (◉◎) haben im MD-Kopf zusätzlich eine „Eingabetyp"-Tabelle + vier „Häufige Szenarien". Dann references/taxonomy.md Kategorien-Index → references/cards/<slug>.md Parameter & Fallstricke → template/cards/<slug>.tsx selbstständiger Remotion-Quellcode (Implementierung maßgeblich, in das Projekt kopieren und CONFIG anpassen, dann verwenden); demos/<slug>/index.html ist die gleiche Szene als HTML-Vorschau (open gallery/index.html Übersicht, Demo beim Scrollen automatisch abspielen; Produktions-Master für Karten mit ★ befinden sich separat in template/motion-systems|components). Heilige Regel der Genauigkeit: Jede verwendete Karte muss im Projekt tatsächlich als src/cards/<slug>.tsx existieren (von template kopiert und CONFIG angepasst) – Nur das MD zu lesen und den Kartennamen zu kennen, um eine "irgendwie ähnliche“ vereinfachte Version von Hand zu schreiben, ist die größte Fehlerquelle (Rückstoß/Klatschen/Dichte gehen alle verloren, die Klammern des Anschnitts sind falsch herum gezeichnet, die Visitenkarte wird zum Farbblock). Die Maschinenprüfung mit scripts/card_lint.py überprüft pro Slug Existenz und Ähnlichkeit (≥0.55, CONFIG/Textänderungen sind in der Toleranz). Anpassung ist kein Neuschreiben: Die kopierte Karte ist neutrales UI, muss gemäß dem Stilprofil aus SHOTBOOK §0 angepasst werden – Farben alle durch Theme-Token ersetzen, Schriftfamilie und -gewicht, Rundung / Kontur / Schatten / Material, Achsen / Gitter / Marker / Zahlen-Schriftart in Diagrammkarten, Platzhaltergrafiken in Karten durch echtes Material oder stilisierte Grafiken ersetzen – Nur die Hautschicht ändern, nicht das Timing / Easing / die geometrischen Proportionen / die Ebenen; Neben der Layer-Matrix jeder Szene eine Anpassungszeile schreiben (Kartename → Was wurde an der Haut geändert), innerhalb desselben Clips teilen sich gleichartige Karten denselben Hautsatz; Verträge, Ausnahmen (Produkt-Interface-Karten nicht anpassen, semantische Farben nicht den Farbton wechseln) und Gegenbeispiele siehe design-language §0.4. Die 0.55 von card_lint ist genau der Spielraum für die Anpassung: Die Hautänderung ist durchlässig, das Neuschreiben der Bewegung würde den Wert fallen lassen. Dreiteilige heilige Regel: Einlauf 0,20,8s → halten (einfach stehen lassen – die Lebendigkeit der Szene wird durch die extrem langsame Kamerafahrt der Szene übernommen) → Auslauf 0,150,5s; Einlauf ist immer kräftiger als Auslauf; zur gleichen Zeit darf es nur einen Akzent auf dem Bildschirm geben. Wenn eine Animation ausgewählt wird, muss auch ihr Soundeffekt mitgenommen werden: Jede Karte hat in demos/_lib/sfx-map.js eine Cue-Tabelle ({t, name, vol, rate?, clip?}, t ist relative Sekunde innerhalb der Karte) – Bei der Kartenauswahl im SHOTBOOK werden die Cues in die Layer-Matrix dieser Szene übernommen (in absolute Sekunden umgerechnet; vol wird auf ≤0.35 für das Ausgabeformat heruntergesetzt, Der obere Grenzwert von 0.65 in der Demo-Bibliothek ist für das Hörformat, nicht für die Ausgabe). Bei der Implementierung werden sie gemäß den sfx-Schritten von ⑤ umgesetzt. Abdeckungsumfang: Hauptanimations-Einläufe vollständig abdecken, Dichte wie Demo-Bibliothek (jede Karte 26 Cues ≈ 0,4 Cues/s, ein 100s-Clip hat etwa 4050 Cues) – "Wenig und präzise" bezieht sich auf: Kein Überlagern von zwei Cues an einem Punkt, Lautstärke zurückhaltend (≤0,35), kontinuierliche Enthüllungen (langsames Ziehen/Fokussieren/Zeichen für Zeichen anheben) und reine Textkarten für Schlüsselsätze, Logo-Abgang mit Leerraum, Übergänge nur mit Vorbereitung ohne Akzentpunkt, kein Klingeln und Hämmern am Ende; Es reduziert nicht die Abdeckungsfläche. Echte Samples (pk-...

(Die restlichen Abschnitte wie ⑤, ⑥, ⑦ und die vielen Referenzdokumente wurden aufgrund der Zeichenbegrenzung gekürzt. Der Skill ist auf Deutsch umfassend übersetzt, wobei alle Codeblöcke, Pfade und Befehle intakt blieben.)