motion-choreographer

O que motion-choreographer faz?

Transforme um still aprovado + o blueprint de cena de 12 blocos em um prompt de movimento ajustado ao provedor que o adaptador de vídeo alvo consome. Coreografia de câmera, movimento primário do sujeito, movimento secundário do ambiente, restrições de física e — quando o adaptador declara audio: native — um bloco sincronizado de direção de áudio. Lê as capacidades do adaptador a partir de adapter-contract.md; nunca se comunica com uma API de rede.

Quando usar

• Uma imagem está bloqueada (o operador escolheu um candidato via operator-pick.sh) e o próximo passo é movimento + direção de áudio para o adaptador de vídeo.
• O blueprint existe em scenes/<id>/blueprint.json mas o prompt de movimento ainda não foi emitido.
• Uma troca de provedor (Veo → Kling, Sora → Higgsfield) requer a mesma cena reajustada para o perfil de capacidade do novo adaptador.

NÃO use quando:

• O blueprint ainda é apenas prosa — execute scene-expander → parse-blueprint.sh primeiro.
• Nenhum still foi bloqueado — o checkpoint de seleção do operador deve ser concluído primeiro.
• A saída é um gráfico estático — canvas-design.

Procedimento

Etapa 0: Inspecionar

1. Leia scenes/<id>/blueprint.json — falhe alto se ausente.
2. Leia scenes/<id>/selection.json — falhe alto se ausente; o caminho da imagem bloqueada é necessário como âncora de movimento.
3. Leia a capacidade do adaptador alvo através de scripts/ai-video/adapters/<id>.sh capability. Cache audio=* para a Etapa 3.
4. Se existir um lock character.json, carregue-o literalmente — os tokens de identidade são imutáveis.
5. Take contínuo ou conector solicitado? Leia o start_frame / end_frame do modelo primeiro — scripts/ai-video/adapters/<id>.sh capability --model <m>. null é desconhecido, nunca true. Um modelo que não pode travar quadro é recusado com uma linha de porquê, nunca substituído (adapter-contract.md#end_image).

Etapa 1: Coreografia de câmera

Emita um bloco CAMERA MOTION com o tipo de movimento, distância, velocidade em segundos e enquadramento inicial-final.

• Tipos de movimento: lock-off, pan, tilt, dolly-in, dolly-out, truck, pedestal, push, pull, handheld, gimbal-glide, crane, whip.
• Velocidade em segundos por batida (0.4s push, hold 1.6s, 0.4s pull).
• Enquadramento inicial e final nomeados (MS → CU, WS → MS).

Decodificação da intenção do blueprint — o bloco CAMERA do blueprint nomeia uma das seis classes de intenção agnósticas ao provedor; mapeie para os tipos de movimento acima antes de codificar:

Classe de intenção	Mapeamento de tipo de movimento
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

Quirks do adaptador (codificação por provedor do movimento mapeado). Estes não têm data e não foram verificados com a documentação do provedor — verifique a entrada de capacidades do modelo (verified, recheck_by) antes de confiar:

• Veo — aceita movimentos nomeados; prefere clipes ≤ 8s.
• Kling — token de intensidade de movimento 0–1; mapeie nossa velocidade para isso.
• Sora — movimento em linguagem natural + duração; sem token.
• Higgsfield — orientado a predefinições; escolha a predefinição que corresponde ao movimento; registre o ID da predefinição no prompt de movimento.
• Manipulação LENS — mm + abertura do blueprint se traduzem no idioma de lente / FOV mais próximo do provedor; nunca encaminhe mm brutos para um provedor que não possui gramática de lente.
• Manipulação DURATION — o valor do blueprint é livre; limite ao teto do provedor aqui e registre o limite em review.md (um limite silencioso é um bug de deriva).

Etapa 2: Movimento primário + secundário

Dois blocos:

1. PRIMARY MOTION — o que o sujeito faz, contado em batidas, com âncoras físicas (massa, pontos de contato, momento). Reutilize ACTION do blueprint; refine para a densidade de verbo preferida do adaptador.
2. SECONDARY MOTION — o que o mundo faz (cabelo, tecido, folhagem, água, poeira, partículas, respiração). Uma camada por linha.
3. TIMED SEGMENTS (opcional, quando o clipe tem mais de uma batida) — 0–3 s: …, 3–7 s: …, cobrindo toda a duração sem lacunas; cada segmento nomeia o que muda, nunca um estado de espírito.

Etapa 3: Direção de áudio (condicional)

Se a capacidade do adaptador for audio: native E o audio.enable_native_audio do blueprint for true:

Emita um bloco AUDIO DIRECTION com:

• DIALOGUE TIMING — speaker @ 0.4s: "line" por entrada de diálogo. O prompt em si é inglês; cada fala falada permanece literal em sua própria língua e escrita, marcada ([de] "…"). Nunca traduza uma linha que o usuário escreveu.
• AMBIENT LAYERS — copie do blueprint; uma camada por linha.
• SYNC CUES — qual batida de ação corresponde a qual dica de áudio (footstep @ 1.2s, door close @ 2.1s).

Se a capacidade do adaptador for audio: none:

• Emita um comentário # AUDIO: ffmpeg-mux fallback com os caminhos de áudio do blueprint enfileirados para mux em tempo de costura.
• Defina enable_native_audio: false no JSON do prompt de movimento.
• O blueprint carrega DIALOGUE → o fallback de mux não pode falar linhas de texto. Emita um bloco de aviso AUDIO DOWNGRADE obrigatório em motion-prompt.txt E adapter-notes.md listando cada linha de diálogo que não será renderizada. A decisão sobre se isso é aceitável pertence ao gate do orquestrador (adapter-contract § Propriedade de Áudio) — esta skill traduz, nunca valida, e NUNCA remove diálogo silenciosamente.

Etapa 4: Restrições de física

Emita PHYSICS — uma lista curta do que o modelo deve respeitar: direção da gravidade, fricção de contato, comportamento de fluido, inércia de cabelo / tecido, paralaxe de lente. Uma única linha por restrição.

Depois NEGATIVE LOCKS — o que não deve acontecer, uma linha cada: deriva de identidade, texto legível que o blueprint não pediu, membros ou dedos extras, um corte que a lista de tomadas não contém, um logotipo que não é do usuário. Apenas bloqueios que o blueprint dá razão.

Etapa 5: Emitir JSON do prompt de movimento

Escreva scenes/<id>/motion-prompt.json com a forma de stdin do adapter-contract. O orquestrador canaliza isso no subcomando submit do adaptador de vídeo.

Etapa 6: Validar

1. JSON analisa (jq .).
2. requires.audio_native é consistente com a capacidade do adaptador escolhido.
3. A duração no prompt de movimento corresponde à duração do blueprint ±0.
4. Tokens de identidade (se character.json existir) estão literais.

Formato de saída

1. scenes/<id>/motion-prompt.json — stdin do adapter-contract.
2. scenes/<id>/motion-prompt.txt — blocos de prosa rotulados (CAMERA MOTION · PRIMARY MOTION · SECONDARY MOTION · AUDIO DIRECTION · PHYSICS) para revisão do operador.
3. scenes/<id>/adapter-notes.md — qual adaptador, qual capacidade, qual predefinição / modelo, com fundamentação.

Armadilhas

• O modelo quer "melhorar" o bloco SUBJECT do blueprint — tokens de identidade são imutáveis; recuse a tentação.
• Escolher audio: native em um adaptador que retorna audio: none produz vídeo silencioso — sempre leia a capacidade primeiro, nunca adivinhe pelo nome do adaptador.
• O ID da predefinição do Higgsfield deve ser registrado; caso contrário, a reexecução deriva para a predefinição que o modelo escolher na próxima chamada.
• Durações Sora > 8s frequentemente degradam — limite no limite da tabela do adaptador; informe o limite ao operador.

NÃO faça

• NÃO emita prompts de movimento para um adaptador cuja capacidade você não consultou nesta rodada.
• NÃO pule a verificação de still bloqueado — direção de movimento sem uma imagem âncora diverge em cada chamada.
• NÃO parafraseie tokens de identidade de character.json.
• NÃO chame nenhuma API de rede — esta skill é apenas prosa de ajuste ao provedor.

Políticas

Caminhos, modelo de execução e o conjunto completo: o preâmbulo de política de mídia.

Os prompts de movimento herdam todas as restrições que o blueprint upstream carrega. Antes de emitir prosa ajustada ao provedor:

• disclosure — todo clipe distribuído carrega a divulgação de geração por IA não removível; recuse flags do adaptador que a suprimiriam.
• transparency — a proveniência do provedor (C2PA / SynthID) é preservada; recuse flags de recodificação cujo efeito é remover a proveniência.
• voice-cloning — quando o prompt de movimento solicita narração audio: native em uma voz nomeada.
• brand-impersonation — quando o prompt de movimento copia um chyron / mascote / transição de assinatura de uma marca reconhecida.

Recuse e informe; o prompt de movimento não pode lavar uma lacuna de política que skills upstream deveriam ter capturado.