motion-choreographer

¿Qué hace motion-choreographer?

Convierte un fotograma fijo aprobado más el plano de escena de 12 bloques en un prompt de movimiento ajustado al proveedor que el adaptador de vídeo objetivo consumirá. Coreografía de cámara, movimiento del sujeto principal, movimiento secundario del entorno, restricciones físicas y — cuando el adaptador declare audio: native — un bloque de dirección de audio sincronizado. Lee las capacidades del adaptador desde adapter-contract.md; nunca se comunica con una API de red.

Cuándo usarlo

• Una imagen está bloqueada (el operador eligió un candidato mediante operator-pick.sh) y el siguiente paso es la dirección de movimiento + audio para el adaptador de vídeo.
• El plano (blueprint) existe en scenes/<id>/blueprint.json pero el prompt de movimiento aún no se ha emitido.
• Un cambio de proveedor (Veo → Kling, Sora → Higgsfield) requiere la misma escena reajustada para el nuevo perfil de capacidades del adaptador.

NO usar cuando:

• El plano sigue siendo solo prosa — ejecuta primero scene-expander → parse-blueprint.sh.
• Ningún fotograma fijo ha sido bloqueado — el punto de control de selección del operador debe completarse primero.
• La salida es un gráfico fijo — canvas-design.

Procedimiento

Paso 0: Inspeccionar

1. Lee scenes/<id>/blueprint.json — falla de forma audible si falta.
2. Lee scenes/<id>/selection.json — falla de forma audible si falta; la ruta de la imagen bloqueada es necesaria como ancla del movimiento.
3. Lee la capacidad del adaptador objetivo mediante scripts/ai-video/adapters/<id>.sh capability. Almacena en caché audio=* para el Paso 3.
4. Si existe un bloqueo character.json, cárgalo textualmente — los tokens de identidad son inmutables.
5. ¿Toma continua o conector solicitado? Lee primero start_frame / end_frame del modelo — scripts/ai-video/adapters/<id>.sh capability --model <m>. null es desconocido, nunca true. Un modelo que no puede bloquear fotogramas es rechazado con una línea de explicación, nunca sustituido (adapter-contract.md#end_image).

Paso 1: Coreografía de cámara

Emitir un bloque CAMERA MOTION con el tipo de movimiento, distancia, velocidad en segundos, y encuadre inicial y final.

• Tipos de movimiento: lock-off, pan (paneo), tilt (inclinación), dolly-in, dolly-out, truck (desplazamiento lateral), pedestal, push (empuje), pull (tracción), handheld (cámara al hombro), gimbal-glide (deslizamiento con estabilizador), crane (grúa), whip (latigazo).
• Velocidad en segundos por pulso (0.4s push, hold 1.6s, 0.4s pull).
• Encuadre inicial y final nombrados (MS → CU, WS → MS).

Decodificación de la clase de intención del plano — el bloque CAMERA del plano nombra una de seis clases de intención independientes del proveedor; mapearla a los tipos de movimiento anteriores antes de codificar:

Clase de intención	Mapeo de tipo de movimiento
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 / arco mediante truck+pan

Particularidades del adaptador (codificación por proveedor del movimiento mapeado). Estas no tienen fecha y no están verificadas contra la documentación del proveedor — verificar la entrada de capacidades del modelo (verified, recheck_by) antes de confiar en una:

• Veo — acepta movimientos nombrados; prefiere clips ≤ 8 s.
• Kling — token de intensidad de movimiento 0–1; mapear nuestra velocidad a ese.
• Sora — movimiento en lenguaje natural + duración; sin token.
• Higgsfield — basado en preajustes; elegir el preajuste que coincida con el movimiento; registrar el id del preajuste en el prompt de movimiento.
• Manejo de LENS — los mm del plano + apertura se traducen al idioma de lente / FOV más cercano del proveedor; nunca enviar mm brutos a un proveedor que carece de gramática de lentes.
• Manejo de DURATION — el valor del plano es libre; limitarlo al techo del proveedor aquí y registrar el límite en review.md (un límite silencioso es un error de deriva).

Paso 2: Movimiento primario + secundario

Dos bloques:

1. PRIMARY MOTION — lo que hace el sujeto, contado en pulsos, con anclas físicas (masa, puntos de contacto, momento). Reutilizar ACTION del plano; refinar para la densidad de verbos preferida del adaptador.
2. SECONDARY MOTION — lo que hace el mundo (cabello, tela, follaje, agua, polvo, partículas, respiración). Una capa por línea.
3. TIMED SEGMENTS (opcional, cuando el clip tiene más de un pulso) — 0–3 s: …, 3–7 s: …, cubriendo toda la duración sin espacios; cada segmento nombra lo que cambia, nunca un estado de ánimo.

Paso 3: Dirección de audio (condicional)

Si la capacidad del adaptador es audio: native Y el plano tiene audio.enable_native_audio como true:

Emitir un bloque AUDIO DIRECTION con:

• DIALOGUE TIMING — speaker @ 0.4s: "line" por entrada de diálogo. El prompt en sí está en inglés; cada línea hablada se mantiene textual en su propio idioma y escritura, etiquetada ([de] "…"). Nunca traducir una línea que el usuario escribió.
• AMBIENT LAYERS — copiar del plano; una capa por línea.
• SYNC CUES — qué pulso de acción se corresponde con qué señal de audio (footstep @ 1.2s, door close @ 2.1s).

Si la capacidad del adaptador es audio: none:

• Emitir un comentario # AUDIO: ffmpeg-mux fallback con las rutas de audio del plano encoladas para la mezcla en tiempo de ensamblaje.
• Establecer enable_native_audio: false en el JSON del prompt de movimiento.
• El plano contiene DIALOGUE → la alternativa de mezcla no puede reproducir líneas de texto. Emitir un bloque de advertencia AUDIO DOWNGRADE obligatorio en motion-prompt.txt Y en adapter-notes.md listando cada línea de diálogo que no se renderizará. La decisión de si eso es aceptable pertenece a la puerta del orquestador (adapter-contract § Propiedad del audio) — esta habilidad traduce, nunca valida, y NUNCA elimina diálogo en silencio.

Paso 4: Restricciones físicas

Emitir PHYSICS — una lista corta de lo que el modelo debe respetar: dirección de la gravedad, fricción de contacto, comportamiento de fluidos, inercia del cabello / tela, paralaje de lente. Una sola línea por restricción.

Luego NEGATIVE LOCKS — lo que no debe suceder, una línea cada uno: deriva de identidad, texto legible que el plano no solicitó, extremidades o dedos extras, un corte que la lista de tomas no contiene, un logotipo que no es del usuario. Solo bloqueos que el plano justifique.

Paso 5: Emitir JSON del prompt de movimiento

Escribir scenes/<id>/motion-prompt.json con la forma de entrada estándar del contrato del adaptador. El orquestador canaliza esto al subcomando submit del adaptador de vídeo.

Paso 6: Validar

1. El JSON se analiza correctamente (jq .).
2. requires.audio_native es coherente con la capacidad del adaptador elegido.
3. La duración en el prompt de movimiento coincide con la duración del plano ±0.
4. Los tokens de identidad (si existe character.json) son textuales.

Formato de salida

1. scenes/<id>/motion-prompt.json — entrada estándar del contrato del adaptador.
2. scenes/<id>/motion-prompt.txt — bloques de prosa etiquetados (CAMERA MOTION · PRIMARY MOTION · SECONDARY MOTION · AUDIO DIRECTION · PHYSICS) para revisión del operador.
3. scenes/<id>/adapter-notes.md — qué adaptador, qué capacidad, qué preajuste / modelo, con justificación.

Trampa

• El modelo quiere "mejorar" el bloque SUBJECT del plano — los tokens de identidad son inmutables; resistirse a la tentación.
• Elegir audio: native en un adaptador que devuelve audio: none produce vídeo silencioso — siempre leer la capacidad primero, nunca adivinar por el nombre del adaptador.
• El id del preajuste de Higgsfield debe registrarse; de lo contrario, la reejecución deriva al preajuste que el modelo elija en la siguiente llamada.
• Las duraciones de Sora > 8 s a menudo se degradan — limitar en el límite de la tabla del adaptador; informar el límite al operador.

NO hacer

• NO emitir prompts de movimiento para un adaptador cuya capacidad no consultaste en esta ronda.
• NO omitir la verificación del fotograma bloqueado — la dirección de movimiento sin una imagen anclada diverge en cada llamada.
• NO parafrasear los tokens de identidad de character.json.
• NO llamar a ninguna API de red — esta habilidad es solo prosa de ajuste al proveedor.

Políticas

Rutas, modelo de aplicación y el conjunto completo: el preámbulo de la política de medios.

Los prompts de movimiento heredan todas las restricciones que el plano ascendente contiene. Antes de emitir prosa ajustada al proveedor:

• disclosure — cada clip distribuido lleva la divulgación no removible de generación por IA; rechazar banderas del adaptador que la suprimirían.
• transparency — la procedencia del proveedor (C2PA / SynthID) se preserva; rechazar banderas de recodificación cuyo efecto sea eliminar la procedencia.
• voice-cloning — cuando el prompt de movimiento solicita narración audio: native con una voz nombrada.
• brand-impersonation — cuando el prompt de movimiento copia un chyron / mascota / transición distintiva de una marca reconocida.

Rechazar y reportar; el prompt de movimiento no puede blanquear una brecha de política que las habilidades ascendentes deberían haber detectado.