# Qué adoptar de OpenMontage en el pipeline AI4M (punto de partida, 9-sep-2026)

Principio: no se adopta código (AGPL) ni el sistema completo. Se adoptan siete ideas de diseño, cada una anclada a un archivo que ya existe en nuestro pipeline.

| # | Idea de OpenMontage | Lo que hoy tenemos | Qué cambiaría | Tallaje |
|---|---|---|---|---|
| 1 | Playbook de estilo en YAML que todas las herramientas leen | Las constantes DOAC viven en `doac1080.py`, las placas en `placas.html`, los gráficos en `_base.css` y `mapa2.html`, la miniatura en prompts sueltos | Un `ai4m-playbook.yaml` con tipografías, verde #00ED91, márgenes, duraciones mínimas, reglas de captions. Cada script lo importa. Captions, placas, gráficos y miniaturas dejan de divergir | S |
| 2 | `edit_decisions` único por episodio, validado con esquema JSON antes de tocar ffmpeg | Un `plan.json` por tipo de overlay (captions en `ep2caps/`, gráficos en `ep1g/`), scripts `tanda1..3.py`, `armar.py` distintos por episodio | Un solo `episodio.json`: cortes de plano, captions, placas, gráficos, audio, con esquema. Un solo `armar.py` que lo lee. Los asserts que hoy están repartidos (no cruzar cortes, mínimo 1,45 s, corrimiento par) pasan al validador | M |
| 3 | Promesa de entrega y riesgo de diapositivas: compuerta ANTES de renderizar | Descubrimos el hueco sin captions de 0:12 y los planos excluidos por solapamiento DESPUÉS de renderizar | `validar_plan.py` que corre sobre el `episodio.json`: huecos máximos sin overlay cuando hay caras, captions solo dentro del plano, gráficos que entran y salen en cortes, tope de segundos seguidos de gráfico a pantalla completa, sin dos overlays en el mismo instante. Bloquea el render si falla | S |
| 4 | `final_review.json` obligatorio tras el render, con esquema | `verificar.py` distinto por proyecto, salida en texto | Un `final_review.json` estándar: cuadros, hash de audio, loudness, presencia y ausencia de cada overlay, md5 servido. Lo consumen el handoff y `content-audit-gate` en vez de leer stdout | S |
| 5 | Registro de decisiones con motivo (decision log) | Las decisiones viven en memoria de Claude y en el chat (corr=0 en planos con rótulo, anclas de palabras, g6 dos veces) | `decisiones.jsonl` por episodio: fecha, decisión, motivo, quién aprobó. Es literalmente la tesis del episodio 2: el registro no envejece, el documento sí | S |
| 6 | Reglas CHAI del revisor: cada hallazgo es preciso, completo y constructivo | `content-audit run --print md` entrega un informe de correcciones | Formato fijo por hallazgo: minuto exacto, misma clase buscada en el resto del video, arreglo propuesto. Un hallazgo sin arreglo se etiqueta "investigar", no "crítico" | S |
| 7 | Costo: estimar, reservar, conciliar, con aprobación por acción | Disciplina de costo en memoria (MuAPI), sin registro por episodio | `costos.jsonl` por episodio: cada generación (Pikzels, HeyGen, Whisper en horas de CPU, MuAPI) con estimado y real. Umbral de aprobación por acción | S |

Dos ideas más, para después:

- **Tablero vivo (Backlot)**: una página en playgrounds generada desde `episodio.json`, `final_review.json` y `decisiones.jsonl`, con la hoja de contacto de cada overlay y su estado (propuesto, aprobado, renderizado). Reemplaza las hojas estáticas por tanda. Tallaje M.
- **Arranque desde un video de referencia**: formalizar lo que hicimos con el video de Caleb como salida fija del análisis: qué se conserva, qué se cambia, costo estimado, muestra antes de producir. Tallaje S, va en el skill de análisis de YouTube.

## Orden sugerido

1. Playbook YAML (1) y validador previo al render (3): son los que evitan retrabajo mañana mismo.
2. `final_review.json` (4) y decision log (5): dejan el episodio 3 documentado desde el inicio.
3. `edit_decisions` único (2): se hace con el episodio 3, no reescribiendo los episodios 1 y 2.
4. CHAI en content-audit (6) y costos (7).

## Qué no adoptar

- El orquestador "agent-first" sin código: nuestro armado por tramos con conteo exacto de cuadros es más confiable que dejar que el modelo escriba los comandos cada vez.
- Remotion como renderer del episodio largo: nuestro ffmpeg por tramos reemplaza un segmento en segundos; Remotion re-renderiza.
- El revisor LLM como juez visual: la aprobación por hoja de contacto de Roberto sigue siendo la compuerta.