motion-choreographer

Was macht motion-choreographer?

Verwandle ein freigegebenes Standbild und das 12-Block-Szenen-Blueprint in einen anbieteroptimierten Bewegungs-Prompt, den der Ziel-Video-Adapter nutzt. Kamerachoreografie, primäre Subjektbewegung, sekundäre Umgebungsbewegung, Physik-Constraints und – wenn der Adapter audio: native deklariert – einen synchronisierten Audio-Direktionsblock. Liest Adapter-Fähigkeiten aus adapter-contract.md; kommuniziert nie mit einer Netzwerk-API.

Wann verwenden

• Ein Bild ist freigegeben (der Operator hat einen Kandidaten via operator-pick.sh ausgewählt) und der nächste Schritt ist Bewegungs- + Audio-Direktion für den Video-Adapter.
• Das Blueprint existiert unter scenes/<id>/blueprint.json, aber der Bewegungs-Prompt wurde noch nicht erstellt.
• Ein Anbieterwechsel (Veo → Kling, Sora → Higgsfield) erfordert, dass dieselbe Szene für das neue Fähigkeitsprofil des Adapters optimiert wird.

NICHT verwenden, wenn:

• Das Blueprint noch reiner Prosa-Text ist – führe zuerst scene-expander → parse-blueprint.sh aus.
• Noch kein Standbild freigegeben ist – der operator-gesteuerte Checkpoint muss zuerst abgeschlossen sein.
• Das Ergebnis ein Standbild ist – canvas-design.

Ablauf

Schritt 0: Prüfen

1. Lese scenes/<id>/blueprint.json – breche mit Fehler ab, falls nicht vorhanden.
2. Lese scenes/<id>/selection.json – breche mit Fehler ab, falls nicht vorhanden; der Pfad des freigegebenen Bildes wird als Bewegungsanker benötigt.
3. Lese die Fähigkeiten des Ziel-Adapters via scripts/ai-video/adapters/<id>.sh capability. Cache audio=* für Schritt 3.
4. Falls eine character.json-Sperre existiert, lade sie wortwörtlich – Identitäts- Tokens sind unveränderlich.
5. Wurde ein Continuous Take oder Connector angefragt? Lese zuerst die start_frame / end_frame des Modells – scripts/ai-video/adapters/<id>.sh capability --model <m>. null bedeutet unbekannt, niemals true. Ein Modell, das keine Frame-Sperre unterstützt, wird mit einer einzeiligen Begründung abgelehnt, niemals stillschweigend ersetzt (adapter-contract.md#end_image).

Schritt 1: Kamerachoreografie

Erzeuge einen CAMERA MOTION-Block mit Bewegungstyp, Distanz, Geschwindigkeit in Sekunden und Start-/End-Framing.

• Bewegungstypen: lock-off, pan, tilt, dolly-in, dolly-out, truck, pedestal, push, pull, handheld, gimbal-glide, crane, whip.
• Geschwindigkeit in Sekunden pro Beat (0.4s push, hold 1.6s, 0.4s pull).
• Start- und End-Framing benannt (MS → CU, WS → MS).

Dekodierung der Blueprint-Intent-Klasse – der CAMERA-Block des Blueprints benennt eine von sechs anbieterneutralen Intent-Klassen; mapping auf die oben genannten Bewegungstypen vor der Kodierung:

Intent-Klasse	Mapping Bewegungstyp
static hold	lock-off
push-in	push / dolly-in
pull-back	pull / dolly-out
lateral track	truck / pan
handheld drift	handheld / gimbal-glide
orbit	crane / arc via truck+pan

Adapter-Besonderheiten (anbieterspezifische Kodierung der gemappten Bewegung). Diese sind undatiert und nicht gegen die Anbieterdokumentation verifiziert – prüfe den Model-Capabilities-Eintrag (verified, recheck_by), bevor du einem vertraust:

• Veo – akzeptiert benannte Bewegungen; bevorzugt Clips ≤ 8s.
• Kling – Bewegungsintensität als 0–1 Token; mapping unserer Geschwindigkeit darauf.
• Sora – natürlichsprachliche Bewegung + Dauer; kein Token.
• Higgsfield – preset-gesteuert; wähle das Preset, das zur Bewegung passt; notiere die Preset-ID im Bewegungs-Prompt.
• LENS-Handling – Brennweite + Blende aus dem Blueprint werden in die nächstgelegene Linse / Sichtfeld-Idiom des Anbieters übersetzt; gib niemals rohe mm an einen Anbieter weiter, der keine Linsen-Grammatik besitzt.
• DURATION-Handling – der Blueprint-Wert ist frei; begrenze ihn auf die Obergrenze des Anbieters und notiere die Begrenzung in review.md (eine stille Begrenzung ist ein Drift-Fehler).

Schritt 2: Primäre + sekundäre Bewegung

Zwei Blöcke:

1. PRIMARY MOTION – was das Subjekt tut, taktgenau, mit physikalischen Ankern (Masse, Kontaktpunkte, Impuls). Verwende ACTION aus dem Blueprint wieder; verfeinere für die bevorzugte Verb-Dichte des Adapters.
2. SECONDARY MOTION – was die Welt tut (Haare, Stoff, Laub, Wasser, Staub, Partikel, Atem). Eine Zeile pro Ebene.
3. TIMED SEGMENTS (optional, wenn der Clip mehr als einen Beat hat) – 0–3 s: …, 3–7 s: …, die gesamte Dauer lückenlos abdeckend; jedes Segment benennt, was sich ändert, nie eine Stimmung.

Schritt 3: Audio-Direktion (bedingt)

Wenn die Adapter-Fähigkeit audio: native ist UND das Blueprint audio.enable_native_audio auf true gesetzt hat:

Erzeuge einen AUDIO DIRECTION-Block mit:

• DIALOGUE TIMING – speaker @ 0.4s: "line" pro Dialogeintrag. Der Prompt selbst ist Englisch; jede gesprochene Zeile bleibt wortwörtlich in ihrer eigenen Sprache und Schrift, getaggt ([de] "…"). Übersetze niemals eine vom Benutzer geschriebene Zeile.
• AMBIENT LAYERS – aus dem Blueprint kopieren; eine Zeile pro Ebene.
• SYNC CUES – welcher Action-Beat zu welchem Audio-Cue gehört (footstep @ 1.2s, door close @ 2.1s).

Wenn die Adapter-Fähigkeit audio: none ist:

• Erzeuge einen # AUDIO: ffmpeg-mux fallback-Kommentar mit den Audio-Pfaden des Blueprints, die für das Stitch-Zeit-Muxing vorgemerkt sind.
• Setze enable_native_audio: false im Bewegungs-Prompt-JSON.
• Das Blueprint enthält DIALOGUE → der Mux-Fallback kann keine Textzeilen sprechen. Erzeuge einen obligatorischen AUDIO DOWNGRADE-Warnblock in motion-prompt.txt UND adapter-notes.md, der jede Dialogzeile auflistet, die nicht wiedergegeben wird. Die Entscheidung, ob dies akzeptabel ist, liegt beim Orchestrator-Gate (Adapter-Contract § Audio Ownership) – dieses Skill übersetzt, es validiert nie und es ENTFERNT NIEMALS stillschweigend Dialog.

Schritt 4: Physik-Constraints

Erzeuge PHYSICS – eine kurze Liste dessen, was das Modell respektieren muss: Schwerkraftrichtung, Kontaktreibung, Fluidverhalten, Haar-/Stoff- Trägheit, Linsen-Parallaxe. Eine Zeile pro Constraint.

Dann NEGATIVE LOCKS – was nicht passieren darf, eine Zeile pro Eintrag: Identitätsdrift, lesbarer Text, den das Blueprint nicht angefragt hat, zusätzliche Gliedmaßen oder Finger, ein Schnitt, den die Shot-List nicht enthält, ein Logo, das nicht dem Benutzer gehört. Nur Sperren, die das Blueprint begründet.

Schritt 5: Bewegungs-Prompt-JSON ausgeben

Schreibe scenes/<id>/motion-prompt.json in der stdin-Form des Adapter-Contracts. Der Orchestrator piped dies in das submit-Unterkommando des Video-Adapters.

Schritt 6: Validieren

1. JSON parst (jq .).
2. requires.audio_native ist konsistent mit der Fähigkeit des gewählten Adapters.
3. Dauer im Bewegungs-Prompt stimmt mit der Blueprint-Dauer überein ±0.
4. Identitäts-Tokens (falls character.json existiert) sind wortwörtlich.

Ausgabeformat

1. scenes/<id>/motion-prompt.json – stdin des Adapter-Contracts.
2. scenes/<id>/motion-prompt.txt – beschriftete Prosa-Blöcke (CAMERA MOTION · PRIMARY MOTION · SECONDARY MOTION · AUDIO DIRECTION · PHYSICS) zur Operator-Überprüfung.
3. scenes/<id>/adapter-notes.md – welcher Adapter, welche Fähigkeit, welches Preset / Modell, mit Begründung.

Fallstricke

• Das Modell möchte den SUBJECT-Block des Blueprints „verbessern“ – Identitäts-Tokens sind unveränderlich; widerstehe der Versuchung.
• Die Wahl von audio: native bei einem Adapter, der audio: none zurückgibt, erzeugt stummes Video – lies immer zuerst die Fähigkeit, rate niemals vom Adapternamen.
• Die Higgsfield-Preset-ID muss notiert werden; andernfalls driftet der Wiederholungslauf zu dem Preset, das das Modell beim nächsten Aufruf wählt.
• Sora-Dauern über 8s verschlechtern sich oft – begrenze auf das Adapter-Tabellenlimit; informiere den Operator über die Begrenzung.

NICHT

• Erzeuge KEINE Bewegungs-Prompts für einen Adapter, dessen Fähigkeiten du nicht in diesem Durchlauf abgefragt hast.
• Überspringe NICHT die Prüfung auf freigegebenes Standbild – Bewegungsdirektion ohne verankertes Bild driftet bei jedem Aufruf.
• Paraphrasiere NICHT Identitäts-Tokens aus character.json.
• Rufe KEINE Netzwerk-API auf – dieses Skill ist reine Anbieter-optimierte Prosa.

Richtlinien

Pfade, Durchsetzungsmodell und der vollständige Satz: Media Policy Preamble.

Bewegungs-Prompts erben alle Constraints, die das upstream Blueprint trägt. Vor dem Ausgeben anbieteroptimierter Prosa:

• disclosure – jeder verteilte Clip trägt den nicht entfernbaren KI-Generierungs- Hinweis; lehne Adapter-Flags ab, die ihn unterdrücken würden.
• transparency – die Anbieterherkunft (C2PA / SynthID) bleibt erhalten; lehne Re-encode-Flags ab, die die Herkunft entfernen.
• voice-cloning – wenn der Bewegungs-Prompt audio: native-Erzählung in einer benannten Stimme anfordert.
• brand-impersonation – wenn der Bewegungs-Prompt einen bekannten Marken-Chyron / Maskottchen / signierte Transition kopiert.

Ablehnen und an die Oberfläche bringen; der Bewegungs-Prompt kann keine Richtlinienlücke bereinigen, die upstream Skills hätten abfangen sollen.