remotion-assembly

Línea de Ensamblaje de Locución (v3 hub, originado en 0715-01 Ensamblaje + iteraciones v3/v4)

Este archivo es el hub del proceso de ensamblaje: solo contiene el esqueleto del flujo y el enrutamiento. Los detalles de cada sección están en los archivos en references/ (el punto de consolidación de 77 diferencias de brecha, finalizado tras una revisión de comparación en profundidad el 2026-07-16).

§0 Comprobación de Preparación del Entorno (Ejecuta esta sección cada vez que seas invocado. No continúes hasta que pase.)

Para que las reglas de este skill se apliquen, necesitas un proyecto Remotion con una base. No imprimas instrucciones para que el usuario lo haga él mismo; ejecuta directamente la comprobación a continuación y añade lo que falte.

Orden de Comprobación (Ejecuta cada elemento de forma secuencial. Solo continúa cuando todo esté en verde.)

# 1) Entorno de ejecución básico
node -v && ffmpeg -version | head -1
# 2) Comprobar si el directorio actual es un proyecto Remotion
[ -f package.json ] && grep -q '"remotion"' package.json && echo "OK: proyecto Remotion"
# 3) Comprobar si la base está completa (si falta alguna, está incompleta)
ls src/design/tokens.ts src/design/motion.ts src/koubo/scenes/shared.tsx \
 scripts/render-service.cjs scripts/qc-master.mjs 2>/dev/null

Manejo de los Tres Resultados

Resultado	Acción
Todo verde	Pasar en silencio. No informes al usuario sobre el estado del entorno. Ve directamente al flujo de ensamblaje.
Hay proyecto, falta la base	Instálala automáticamente, no preguntes. (Cuando el setup detecte que ya es un proyecto Remotion, solo añadirá el skill/scripts/base, sin sobrescribir tu código):macOS/Linux: bash <(curl -fsSL https://raw.githubusercontent.com/jincheng2026/jc-remotion-skills/master/setup.sh) .Windows (PowerShell): `irm https://raw.githubusercontent.com/jincheng2026/jc-remotion-skills/master/setup.ps1
No hay proyecto	Pregunta una vez antes de instalar (npm install tarda 3-5 minutos y es voluminoso, es una operación significativa; requiere confirmación del directorio por parte del usuario):"Necesito crear primero un proyecto Remotion (la instalación de dependencias lleva unos 3-5 minutos). ¿Dónde lo creo? Por defecto en ./remotion-koubo-studio"Después de obtener la respuesta: macOS/Linux usa el script setup.sh anterior con el parámetro <directorio>; Windows usa node <repo>/setup.mjs <directorio>
Falta node / ffmpeg	Intenta instalarlos automáticamente. No le des comandos al usuario para que los ejecute. (En la mayoría de los entornos, instalar estos dos con el gestor de paquetes del sistema no requiere privilegios de administrador):① macOS con brew (command -v brew) → Informa "Falta X. Lo instalaré con brew. Tardará unos minutos." y luego ejecuta directamente brew install <solo lo que falta>. Después de la instalación, vuelve a ejecutar esta sección.② Windows con winget → winget install OpenJS.NodeJS Gyan.FFmpeg③ Linux: Primero prueba sudo -n true: si no requiere contraseña, ejecuta sudo apt install -y nodejs ffmpeg; si requiere contraseña, da el comando al usuario para que lo ejecute.④ Si nada funciona (por ejemplo, Mac sin Homebrew) → Da al usuario un comando oficial para instalar Homebrew que pueda pegar en la terminal (necesitará introducir una contraseña una vez). Después de la instalación, pide al usuario que lo confirme y luego vuelve a ejecutar esta sección.

Disciplina

• Ejecútala solo la primera vez que seas invocado. Si ya se ha realizado en la misma sesión, no la repitas.
• Cuando todo esté en verde, mantén el silencio — el usuario quiere editar el video, no un informe del entorno. Solo habla cuando necesites instalar algo.
• Después de la instalación/creación, debes volver a ejecutar la comprobación para confirmar que todo está en verde antes de continuar con el flujo.
• Si el usuario dice explícitamente "Salta la comprobación" o "Sé que el entorno está bien", respeta su decisión y comienza directamente a trabajar.

§0.1 Compuerta de Lectura Obligatoria Antes de Empezar (Ejecútala antes de proponer un plan. Está al mismo nivel que la comprobación del entorno §0: no puedes continuar sin pasarla.)

Este archivo es un hub de enrutamiento, no el contenido. La siguiente tabla es la lista de fuentes reales. Debes leer cada una de ellas por completo antes de producir la tabla del plan de ensamblaje. No es "consúltalo cuando lo necesites".

Lectura Obligatoria	¿De qué se encarga?
references/motion.md del sistema de diseño	Vocabulario de animaciones (scroll numérico / caída de veredicto / crecimiento de líneas / salidas / pantalla limpia), Cinco Reglas de Suavidad
references/typography.md del sistema de diseño	Escala tipográfica T, bandas de espacio, relación del carácter protagonista
references/layout.md del sistema de diseño	Coordenadas de las tres zonas, mecanismo de toma de control, marco de seguridad
references/specs.md del sistema de diseño	Tabla de especificaciones de componentes, tabla de valores numéricos de animaciones
references/subtitle.md de ensamblaje	Segmentación de subtítulos, normas bilingües, compuerta de verificación
references/rhythm.md de ensamblaje	Densidad del ritmo, disciplina de salidas, curva de densidad
references/narrative.md de ensamblaje	Sistema de etiquetas laterales, cinco nodos de energía, actualización de veredicto
references/selection.md de ensamblaje	Tabla de correspondencia: tipo de oración → tipo de párrafo → componente
references/infographic.md del sistema de diseño	Graficación de metáforas, selección de gráficos (lectura obligatoria si hay párrafos con datos/procesos/comparaciones)

¿Por qué se estableció esta compuerta? (2026-07-27, Causa Raíz de Fracaso 0727-01, Nivel 1): En esa versión, solo se leyó este hub + tokens.ts + un archivo de escena existente, y ninguna de las 9 fuentes reales anteriores fue leída. La consecuencia fue que todo el vocabulario de animaciones se redujo a un solo tipo "Fundido de entrada" — los números no rodaban, los veredictos no caían, la mayoría de los párrafos no tenían salidas, no había pantallas limpias entre capítulos — y todo esto estaba escrito explícitamente en motion.md.

Dos reglas disciplinarias adicionales:

• Prohibido inferir normas a partir de un archivo de escena existente. Una escena solo refleja las reglas que utiliza; lo que falta son precisamente las reglas que no utiliza — 0727-01 usó la Escena02 de 0724-01 como plantilla, y esa escena no tenía scroll numérico ni Stamp, por lo que todo el video se quedó sin ellos.
• Cada párrafo en la tabla del plan debe incluir el número de la entrada de la regla (ver §2, Paso 2). Si no puedes escribir "según motion §7 / narrative §3", es que no lo has leído. Vuelve atrás y léelo de nuevo.

§0.2 Vista Previa en Vivo de Studio por Defecto Activada ("Ruta A", Decisión del Usuario 2026-07-28)

El método de iteración por defecto confirmado es la actualización en caliente de Remotion Studio, no la revisión de fotogramas renderizados. El ciclo "cambiar un lugar → renderizar fotogramas → leer imagen" se reserva solo para la aceptación de las compuertas.

• Iniciar la vista previa al comenzar a trabajar: Una vez pasada la comprobación del entorno, inicia Studio por defecto y abre la composición de este video para que el usuario la vea (Claude Code: Panel de vista previa inicia remotion-studio desde .claude/launch.json en la raíz del repositorio; host genérico: npm run dev y pide al usuario que abra http://localhost:3000/Koubo-<NombreDelVideo>). El componente principal tiene un corte bruto base (OffthreadVideo), por lo que en Studio se ve la composición completa (locución + MG + subtítulos + SFX en la misma pantalla). El usuario puede reproducir y arrastrar la línea de tiempo en cualquier momento.
• Iteración mediante actualización en caliente: Después de cambiar el código, se actualiza automáticamente en segundos. Los ajustes de tamaño de fuente, posición, color y texto se ven y deciden directamente en la vista previa. El renderizado de fotogramas (render-service stills/segment) se usa solo para la evidencia de las tres compuertas, la entrada de mg-judge y la aceptación de entrega; las reglas de las compuertas y la revisión permanecen sin cambios (la entrega sigue incluyendo el video terminado con efectos de sonido; la autoinspección de la calidad de las animaciones aún requiere ver el metraje continuo uno mismo, §2.5 Paso 5).
• Panel de Ajuste de Parámetros: El componente principal del nuevo video es generado automáticamente por scaffold-koubo.mjs con un esquema zod (qc / subZhSize / subBottom / sfxGain; el fragmento de registro de Root impreso al final ya incluye schema+defaultProps). Al añadir InfoScrim, se conecta scrimStrength al esquema siguiendo src/koubo/Koubo072701.tsx. Los demás parámetros se añaden/eliminan según el video. Regla de hierro: Los valores por defecto del esquema son siempre iguales a los tokens / valores de decisión actuales. El video se entrega con los valores por defecto. El panel es una capa de exploración, no la fuente de verdad. Los valores finalizados se escriben de vuelta en las fuentes de verdad correspondientes (tamaño de fuente/distancia inferior → tokens.ts; nivel de volumen → flujo sfx §4.4). Está prohibido dejar valores no predeterminados en defaultProps. Los defaultProps de Root hacen referencia a variables de token. El mensaje de Studio "Can't save default props" es un diseño intencional (para bloquear la ruta de evitar los tokens y guardar valores). No lo arregles. La versión de zod está bloqueada según los requisitos de Remotion (4.0.489 ↔ zod 4.3.6; la advertencia de discrepancia de versión al iniciar Studio es la verificación).
• La caída de fotogramas durante la reproducción en tiempo real es un fenómeno normal de la composición en el navegador. Para evaluar la sensación de la animación, reduce a 0.5x o confirma mediante el renderizado del segmento. Cuando Studio está abierto y se inicia un renderizado, la disciplina de serialización permanece sin cambios (#23 bloqueo por concurrencia + zona de advertencia de peligro "Studio+still se cuelgan concurrentemente"). En caso de "proceso al 0% de CPU en silencio", primero verifica la expulsión de iCloud (error #25 y su variante node_modules).

Principios de Iteración del Sistema (El usuario decidió el 2026-07-16: el skill debe iterar continuamente, mejorando los estándares y la calidad).

• Trinquete: solo hacia adelante, nunca hacia atrás. Los estándares decididos por el usuario (valores de especificaciones, elementos rechazados, sintaxis de sonido) son el suelo, no el techo. Los párrafos posteriores solo pueden aumentar las exigencias sobre ellos. Está prohibido mantener el statu quo con el argumento de "la última vez también fue así".
• Cada párrafo debe dejar un legado. Un párrafo aprobado = al menos un "por qué" transferible anotado en el archivo de la sección. Un fracaso = abrir un caso de error (síntoma → ubicación de la solución). Un "no vale" / "más o menos" del usuario = anotar la dirección de mejora (ej: sonido "más o menos bien" → pendiente de actualizar a un paquete comercial).
• Cada video debe ser revisado después de terminar. Antes de ensamblar un nuevo video, revisa primero la colección de errores y los "casos negativos" de cada sección, para confirmar que el punto de partida del nuevo video = el estándar final del video anterior.
• La comparación de calidad no tiene techo. El video de referencia actual es solo una línea de base, no el destino final. Si encuentras una referencia de mayor nivel, absórbela en la tabla de especificaciones usando el método de comparación a nivel de palabra.

Orden de Resolución de Conflictos de Reglas (Cuando dos reglas entren en conflicto, resuélvelo tú mismo según este orden, regístralo y espera la ratificación del usuario.)

Decisión del usuario > Restricciones duras (tres zonas/tabla de ocupación/puerta de control/"sin texto desnudo sobre fondo brillante") > Alineación semántica (salida según lo que se dice) > Línea base de densidad y ritmo > Preferencia estética. Ejemplos de decisiones conocidas: La alineación tiene prioridad sobre la pantalla limpia (rhythm 1). La exención de la disciplina de salida para la explicación de gráficos (rhythm 4, pendiente de verificación a gran escala). La lista rápida no activa la obligación de material de archivo de casos (broll 6). Para nuevos conflictos, resuélvelos según el orden y regístralos explícitamente en el plan. Está prohibido elegir uno en silencio.

Disciplina de la Sesión Principal (Barandilla de Revisión del Flujo Completo 0722-01, establecida el 2026-07-24; ver my-video/docs/0722-01-全流程踩坑复盘-20260723.md)

Tres retrabajos en una noche, dos bloqueos de la máquina. El problema raíz no fue la ejecución, sino el juicio y la alineación. Cuatro reglas de hierro:

1. Antes de adoptar una solución existente / escribir un valor fijo, primero escribe claramente las "condiciones de aplicación". La salida por defecto del skill (ej: la revelación lenta de la animación de montaje de gbro) solo es válida en su propio contexto y no se adapta automáticamente a tu contenido anfitrión. En una locución densa, la revelación lenta = el metraje siempre va un paso por detrás (A1, 8 videos descartados). Un número para todo un lote = asumir que todas las entradas son isomórficas, pero por lo general no lo son (A2 "altura de la persona 45-60%" aplicado a rajatabla causó el fracaso de las tomas de cuerpo entero). Las especificaciones deben anotar "qué valor se usa en qué situación" (ej: metáfora impulsada por objeto 45-60% / metáfora impulsada por persona, primer plano 65-80%), no solo un valor.
2. Las oraciones condicionales del usuario no son oraciones imperativas. "Solo si X, entonces Y" es para dar una restricción, no para pedir X (A3: El usuario dijo "Solo si es B-roll a pantalla completa, entonces la persona desaparece" = por defecto la persona no desaparece; yo lo leí como "Haz que el B-roll sea a pantalla completa", retrabajo de 1.5h a altas horas de la noche). Ante términos ambiguos ("haz que la imagen se mueva" = movimiento de cámara vs movimiento de elementos), primero responde una pregunta para alinear, luego implementa. Cuesta mucho menos que adivinar.
3. La verificación debe poder distinguir entre "probado y no hay problema" y "no se ha probado en absoluto". Para QC "cero infracciones", primero verifica la tasa de cobertura de la sonda (error #35). Para monitorizar tareas largas, vigila la señal específica de la tarea (la propia sesión/producto/PID del proceso de esa tarea), no vigiles globalmente — las tres falsas alarmas de monitorización en 0722-01 fueron por vigilar la señal equivocada (vigilaron la tarea de portada que el usuario ejecutaba en paralelo, usaron "cuánto tiempo hace que el archivo no cambia" para juzgar si estaba vivo, mientras que Codex escribe en lote después de acumular suficiente; la línea roja dura (sin caracteres falsos/logo/marca de agua) debe ser verificada de forma independiente por la sesión principal con ampliación, no confíes en el autoexamen del subagente (C5: El autoexamen de 07 dijo "sin caracteres falsos en los cuatro bordes", pero en realidad había letras en el borde superior).
4. Al terminar una versión / entrega, haz un commit de git. El proyecto es un repositorio git, pero nunca se ha hecho commit → cuando el código de la escena v5 fue sobrescrito por la versión de pantalla completa, solo se pudo reconstruir basándose en las imágenes renderizadas, con una precisión reducida (D3). Después de completar una versión o antes de la entrega, git add -A && git commit. La pérdida de código es la única pérdida irreversible en todo el flujo.

Si la base tiene defectos, arregla la base o abre un caso de error. Está prohibido parchear solo en un segmento (error #36 InfoScrim: parche local en 0715-02, el hueco persistió hasta que explotó en 0722-01).

Tabla de Enrutamiento de Secciones (Qué archivo leer para cada paso del ensamblaje)

Sección	Archivo	¿De qué se encarga?
Selección de Tipo de Oración (Primer punto de consulta)	references/selection.md	Tabla de correspondencia: tipo de oración de locución → tipo de párrafo → puntero gramatical → componente; criterios de las tres secuencias principales de fotografía; salida sin coincidencia
I+D sin referencia	references/rd-noref.md	Diseño de nuevo arreglo cuando hay un hueco gramatical + sin video de referencia: generación de múltiples planes → panel de juicio → decisión del usuario
Réplica de video de referencia (Modo de I+D - Capa de método A)	Skill independiente remotion-reference-fidelity	Metodología de fidelidad para réplica de videos de referencia: seis tipos de gramática de escena, tabla de ritmo a nivel de palabra, compuerta de fidelidad; solo se encarga de "cómo leer fielmente el video de referencia"; los valores numéricos se basan en las fuentes de verdad de cada sección; la condición de activación de la línea de entrega alfa también está en él (ver §6)
Narrativa de capítulos	references/narrative.md	Sistema de etiquetas laterales, campamento rojo/verde, momento del golpe, hook/CTA, actualización de veredicto
Densidad y ritmo	references/rhythm.md	Tabla de ritmo, ritmo cada 3-5s, disciplina de salidas, refuerzo de resumen, método de auditoría
Subtítulos	references/subtitle.md	Segmentación semántica de oraciones, oraciones cortas en inglés, caja de fondo, script de verificación
Ingeniería de materiales	references/broll.md (fuente de verdad de reglas) + Skill de ejecución independiente remotion-broll (flujo completo: juicio → recolección → verificación → selección de segmentos → incrustación → corrección de color → renderizado de segmentos; cuando se identifica un segmento de material real, se le llama a trabajar)	Prioridad de material de cuatro niveles (grabación de pantalla propia > video oficial > captura de pantalla > tarjeta de simulación), pipeline de auto-recolección y edición de video, punch-in, unificación de corrección de color
Audio	references/audio.md (fuente de verdad de reglas) + Skill de ejecución independiente remotion-sfx (selección de fuente → tabla de escucha → procesamiento e ingreso → montaje de cue → aceptación cuantitativa; cuando se necesita sonido para un párrafo, se le llama a trabajar)	Pipeline de SFX, normas de volumen, loudnorm de master, aceptación cuantitativa
Maquetación/Tipografía/Textura/Animación/Gráficos	references/ del sistema de diseño	layout / typography / texture / motion / infographic
Colección de errores (índice síntoma → solución)	Skill independiente remotion-gotchas-index	Aquí se consulta la ubicación de la solución para todos los "Error #NN" (#18/#19/#23/#24/#25, etc.) en el texto completo

Base de ingeniería (substrate): Este flujo asume que src/design/ (tokens/componentes/motion/sonda QC/FontGuard) + src/koubo/scenes/shared.tsx (conjunto de cuatro elementos de puerta de control + Place + qcAllow) ya están en su lugar — son la base compartida de todo el repositorio, reutilizada para nuevos videos sin reconstruir. Si se arranca en frío sin src/, primero construye la base según el SKILL del sistema de diseño "Lista de base de ingeniería" y luego entra en este flujo.

Flujo Completo de Extremo a Extremo para un Nuevo Video (Sin video de referencia: lista de verificación genérica desde el montaje bruto y SRT hasta el producto final)

Aclaración de posicionamiento (2026-07-20): Sin video de referencia es el estado normal; tener un video de referencia es una excepción. El estado normal = editar una locución original, sin video de referencia correspondiente, seguir la ruta de tipo de oración y gramática de references/selection.md, y aplicar especificaciones de estilo calibradas para producir un plan (esta lista de verificación está escrita para eso). Tener un video de referencia (ej: réplica 1:1 de un video de referencia para calibración de estilo) es solo una excepción, cuyo propósito es calibrar y verificar si el estilo se ha aprendido correctamente. No tomes "alinear fotograma a fotograma con un video de referencia" como el flujo por defecto. Las secciones existentes usan principalmente 0715-01/video de referencia como ejemplo (que era un escenario de calibración con un video de referencia para alinear fotograma a fotograma). Para videos originales sin video de referencia, sigue esta lista de verificación: el flujo genérico está aquí, los detalles de este video van a cada sección correspondiente. Cuando haya un video de referencia, solo inserta antes del paso 4 una "alineación a nivel de palabra de la hoja de contacto del video original" (ver §2 Paso 3 / §2.5 Modo de I+D); los demás pasos son los mismos.

1. Recepción de entrada e ingesta de materiales (§0 + §0.5): Recibe el video montado + SRT. Sigue los siete pasos de §0.5 para convertir "los dos archivos que el usuario lanzó" en un estado listo para trabajar (verificación de mismo video/ubicación/borrador de subtítulos/esqueleto del proyecto/adaptación de codificación dura). Usa ffprobe para determinar fps/resolución. Los parámetros de la composición deben coincidir con el material; no uses por defecto 60fps (error #19 del sistema de diseño). Codifica calculateMetadata.
2. Preguntar al usuario sobre la composición (§1 / layout.md §1): No te tomes la libertad de decidir si el área de información va a la izquierda o a la derecha. Extrae 3-4 fotogramas para ver la posición de la persona y deja que el usuario decida. Por defecto, el MG de información del autor va a la izquierda.
3. Leer completamente el SRT y dividir en capítulos (Paso 1 de §2): Divide en 15-20 segmentos según los puntos de inflexión semánticos. Selecciona un punto principal de empaquetado para cada segmento. Al mismo tiempo, marca los cinco nodos de energía en la línea de tiempo (hook/golpe de veredicto/decisión VS/veredicto a nivel de video/CTA, ver narrative.md §1).
4. Crear el plan según la gramática (Diferencia central sin video de referencia): No hay un video original para copiar el ritmo. Para cada oración, primero consulta la tabla de correspondencia de tipos de oración en references/selection.md para determinar el tipo de párrafo y la gramática principal (incluyendo los criterios de las tres secuencias principales de fotografía). Luego ve a la sección de la fuente de verdad apuntada por el puntero para obtener las especificaciones — narrative determina el esqueleto narrativo y los cinco nodos, rhythm determina el cambio de ritmo y el pico, infographic determina la graficación de metáforas, layout determina las tres zonas y la toma de control. Si no hay coincidencia en la tabla, ve a references/rd-noref.md. Está prohibido diseñar sin base. Genera una tabla de plan de ensamblaje (assembly/<NombreDelVideo>/装配方案.md: intervalo de tiempo | puntos clave de la locución | etiqueta lateral | MG principal | brecha de material), muéstrasela al usuario para su confirmación antes de escribir código.
5. Decidir el modo de I+D/Producción (§2.5): Si todo el arreglo principal de todos los segmentos puede encontrar una correspondencia en la gramática existente = modo de producción en todo el flujo (§2.5.1 cinco fases). Si algún segmento contiene un nuevo patrón de arreglo, asciende a modo de I+D y procede en un bucle segmento por segmento.
6. Implementación + Tres Compuertas (§2.5): Los segmentos de material usan remotion-broll, los segmentos HUD se escriben según los valores medidos de layout, y el sonido usa remotion-sfx. Cada segmento pasa por la sonda QC → mg-judge → revisión final del usuario.
7. Aprobación de la metodología de todo el video (§2.6): Revisa a lo largo de todos los segmentos cinco elementos: presupuesto de color, continuidad de etiquetas laterales, curva de densidad de ritmo, distribución de SFX, elementos repetidos.
8. Cadena de master + Entrega (§5/§6): Después de pasar por la cadena de master (compresión + ganancia cuantitativa + limitador, audio.md regla 2), usa ffprobe para verificar duración/pista de audio/tasa de bits. La entrega incluye evidencia (informe QC + comparación de fotogramas renderizados). Después del final de la entrega o retrabajo, actualiza la línea de estado de este video en STATUS.md en la raíz del proyecto (si no existe, créalo; es el archivo de estado a través de sesiones/agentes, y una nueva sesión que tome el relevo depende completamente de él).

0. Especificaciones de Entrada (Acuerdo de Entrega del Usuario)

• El usuario proporciona: Video montado bruto (los espacios para respirar ya están cortados) + SRT correspondiente. No ejecutes Whisper.
• Contrato de interacción (Decisión del usuario 2026-07-21, nivel de regla de hierro): El usuario solo proporciona tres cosas: ① Montaje bruto + SRT; ② Material solicitado explícitamente (grabación de pantalla/captura de pantalla de B-roll — el IA primero hace una lista según la regla 2 de broll y pide explícitamente los elementos, o el usuario los proporciona activamente); ③ Comentarios y retroalimentación de revisión final en lenguaje natural (dirección de composición, informe de tiempo de sensación auditiva/visual). Aparte de esto, no permitas que el usuario proporcione ningún otro archivo: el plan de ensamblaje, documentos del taller, formularios de retrabajo, tablas de cue, etc., son todos productos internos que el IA crea, lee y continúa por sí mismo. Para retrabajo/continuación, según el paso 1 de §0.5 "Reingreso del mismo video", carga automáticamente los elementos pendientes. Está prohibido pedir al usuario que mueva, pegue o reexprese cualquier documento de proceso.
• Marca de tiempo de SRT = única línea de base para el ensamblaje: Fotograma enterAt = Segundo de inicio de SRT × FPS de la composición.
• Si falta el SRT (solo texto de locución), solo se puede producir una tabla de ritmo a nivel de plan: marca la columna de tiempo como "Estimado". Antes de escribir código, debe recalibrarse con el SRT real. Si no hay montaje bruto para extraer fotogramas, marca el juicio de composición como "Pendiente de decisión".
• Los FPS/resolución de la composición deben coincidir con el material (usa ffprobe primero para verificar, no uses por defecto 60fps). Si no es 1080p@30: la tabla de especificaciones, el número de fotogramas de animación y las aserciones de metadatos en qc-master.mjs deben modificarse en consecuencia. La lista completa de elementos a modificar está en design-system references/motion.md §0 (el conjunto actual de valores calibrados está fijado para 30fps).
• Generación de subtítulos y normas de segmentación → references/subtitle.md.

0.5 Lista de Acciones de Ingesta de Materiales (Paso 0 para comenzar un nuevo video: desde el mp4+SRT proporcionados por el usuario hasta estar listo para trabajar)

0. Autocomprobación del entorno (si no pasa, detente, no hay atajo, genérico para el anfitrión): Bash escribe un archivo de prueba (ej: echo ok > assembly/env-check.txt) → usa un método de lectura de archivos para leerlo y verificar que es visible (Claude=Herramienta Read) → elimínalo. Si la escritura no persiste o no se puede leer al volver a leer = la sesión se ejecuta en modo sandbox, todo producto posterior se evaporará (error #30: toda la prueba 0719-01 se perdió por esto) — detente inmediatamente y pide al usuario que libere los permisos de escritura (Claude=autorizar Bash/Editar; Codex=workspace-write, etc.), luego comienza a trabajar. Prohibidos tres tipos de soluciones alternativas de auto-rescate: enlace simbólico a /tmp para evitar la ruta china (las rutas se ponen entre comillas dobles), auto-deshacer la sandbox (cualquier bandera del anfitrión como dangerouslyDisableSandbox), o copiar el proyecto a otro lugar para trabajar. Todos los productos de archivo deben escribirse en disco usando métodos de escritura de archivos estándar y luego verificarse mediante lectura (Claude=Herramienta Write es la prioridad).
1. Comprobación de mismo video: Compara la duración de ffprobe con los videos existentes en public/footage/. Si la diferencia es ≤1s, se considera el mismo video → pregunta al usuario "¿Reutilizar la implementación anterior o volver a editar como un nuevo video?". Si elige volver a editar, no leas en absoluto el código de escenas del video anterior ni los documentos del taller en assembly/<NombreDelVideo anterior>/ (para evitar copiar respuestas antiguas o sobrescribir accidentalmente el video anterior), y sigue un flujo completamente nuevo con el nuevo nombre del video. Reingreso del mismo video (continuación/retrabajo/cambio de material, Decisión del usuario 2026-07-21): Cuando el usuario dice "continuar" o simplemente arroja un nuevo material, escanea automáticamente los elementos pendientes en assembly/<NombreDelVideo>/分段工坊/segments.md + las entradas no saldadas en docs/<NombreDelVideo>-返工单*.md, los enumera directamente como la lista de tareas de esta ronda y comienza a trabajar. Está prohibido esperar a que el usuario pegue formularios de retrabajo, reexprese el historial o explique qué cambiar (§0 Contrato de interacción).
2. Determinar el nombre del video: MMDD-NN (fecha de grabación-número de serie, ej: 0715-01). Si el usuario especifica un nombre, úsalo.
3. Ubicación del material: Copia el montaje bruto a public/footage/<NombreDelVideo>.mp4. Si la fuente es 4K, primero conviértela a 1080p H264 antes de ponerla en footage (la composición ya es 1080p, y la decodificación de OffthreadVideo con 4K de base puede causar tartamudeo y fotogramas repetidos = congelación de la persona en el producto final, confirmado por 0721-01, ver error #33 — conviértelo en el paso de ingesta, no esperes a que aparezcan fotogramas congelados para retrabajar). Archiva el SRT original en assembly/<NombreDelVideo>/input/ (el SRT es la única línea de base del ensamblaje, debe estar en el repositorio — lección 0715-01: el SRT original no se archivó, solo quedaron los productos generados, imposible de verificar). Los archivos originales del usuario no se tocan.
4. Aceptación: Verifica los elementos ffprobe de §0 + tres elementos del SRT (UTF-8 legible, marcas de tiempo monótonas, hora de finalización del último elemento ≈ duración del video) + Verificación de subtítulos quemados (imprescindible después de ffprobe): usa ffmpeg para extraer 1-3 fotogramas aleatorios y léelos con Read para confirmar visualmente que el montaje bruto no tiene subtítulos quemados/marcas de agua (lección 0715-02: el material de entrega original tenía subtítulos quemados en todo el video, quemados en los píxeles sin un flujo de subtítulos independiente, causando imágenes fantasma con los nuevos subtítulos refinados, no se descubrió hasta que se renderizaron los fotogramas = una ronda completa de QC desperdiciada. Si se descubre, detente y pide al usuario que proporcione una versión sin subtítulos o que decida cómo superponerlos).
5. Borrador de subtítulos: node scripts/srt-to-cues.mjs <archivo_srt_archivado.srt> <NombreDelVideo> para generar mecánicamente un borrador src/koubo/subtitles-<NombreDelVideo>.ts (zh=texto original del SRT, en=vacío). Luego, según las reglas 2/3 de subtitle.md, realiza un reordenamiento semántico, corrección de errores tipográficos (basado en la locución), y traducción al inglés. Solo ensambla cuando check-subs.mjs tenga cero errores. Estos tres pasos son un todo; la traducción al inglés no es opcional — check-subs ahora bloquea si "en está completamente vacío / tasa de cobertura <90%" (caso abierto 2026-07-27: 0727-01 solo hizo el reordenamiento, 77 en estaban completamente vacíos, el producto final se degradó a una sola línea de chino, la versión anterior de check-subs solo verificaba el formato si en no estaba vacío, y lo dejaba pasar en silencio cuando estaba completamente vacío). Si realmente se va a hacer un video monolingüe, pasa explícitamente --mono para separar "esto es una decisión" de "esto es un descuido".
6. Esqueleto del proyecto: node scripts/scaffold-koubo.mjs <NombreDelVideo> <DuraciónEnSegundos> para generar de una sola vez (pista de subtítulos/pista de SFX + tabla de cues vacía/componente principal/directorio scenes-<NombreDelVideo>/ + marcadores de posición/tabla de segmentos del taller, el volumen toma la línea de base actual; al final del script se imprime el fragmento de registro de Root.tsx para pegarlo). El directorio de archivos de segmento está aislado de las scenes/ del video anterior. El bloqueo de archivos es independiente por video para evitar conflictos de nombres. La base compartida todavía se importa desde src/koubo/scenes/shared.tsx.
7. Dos lugares de codificación dura para cambiar de video: COMP_ID/ENTRY del render-service y las aserciones de metadatos de qc-master. Los detalles están en §6 "Modificaciones obligatorias al cambiar de video".

1. Composición y Maquetación de las Tres Zonas → design-system references/layout.md

Pregunta primero al usuario sobre la composición (lección 0715-01: la dirección del área de información no se puede decidir unilateralmente; el usuario decidió colocarla a la izquierda). Las coordenadas de las tres zonas, el mecanismo de toma de control de material (Nivel A: la persona se retira para todo el segmento, sin PiP; la actualización del momento se basa en el aumento del tamaño de fuente + despeje + marco espejo rojo/verde, el nivel B de atenuación ya fue rechazado por el usuario), el momento del protagonista, y las plantillas de agrupación están todas en layout.md — es la única fuente de verdad para la maquetación.

2. Método de Segmentación: Primero el Plan, Luego el Código (Dos Pasos)

1. Leer completamente el SRT y dividir en capítulos: Divide en 15–20 segmentos según los puntos de inflexión semánticos (hook de apertura / punto / caso / metáfora de transición / progresión de tipos / resumen / predicción / final). Selecciona un "punto principal de empaquetado" para cada segmento.
2. Producir la tabla del plan de ensamblaje (assembly/<NombreDelVideo>/装配方案.md): Intervalo de tiempo | Puntos clave de la locución | Etiqueta lateral | MG principal | **Justificación de la regla** | Brecha de material | Modo de carga. Muestra al usuario para su confirmación antes de escribir código. La columna "Justificación de la regla" es el comprobante de aceptación de la compuerta de lectura obligatoria §0.1 (Añadido el 2026-07-27): Para cada segmento, anota el número de entrada de la regla en la que se basa el arreglo principal (ej: motion §7 scroll numérico / narrative §5 actualización de veredicto / selection oración de comparación transversal). Si no se puede anotar el número de entrada = ese segmento fue diseñado basándose en la intuición; vuelve atrás, lee la fuente de verdad y rediseña — esta columna no es un trabajo administrativo; es la única evidencia verificable de "si se ha leído o no" (la tabla del plan de 0727-01 tenía 27 segmentos sin ninguna cita de regla, por lo que todas las animaciones del video se redujeron a un solo tipo de fundido).

El modo de carga de B-roll debe preguntarse primero (Decisión del usuario 2026-07-24, obligatorio para videos apaisados): Al dividir los segmentos, marca aquellos que necesitan B-roll/pantalla en pantalla. Para cada uno de estos segmentos, si el usuario no ha proporcionado el material, toma la iniciativa de incluir tu comprensión y sugiere preguntar al usuario: ¿Este segmento debe ser "B-roll a pantalla completa" (la persona se retira, el material cubre toda la pantalla) o "Tarjeta de pantalla en pantalla" (la persona está presente, el material está en una tarjeta pequeña en el lado derecho, como en 0722-01)? El modo de carga decide tres cosas a la vez: ① Maquetación: cortar a la persona a pantalla completa vs tarjeta + persona permanente (layout §2 regla de hierro); ② Resolución/herramienta: para pantalla en pantalla es suficiente 720p (se puede usar Grok/gbro para collage), para pantalla completa se necesita 1080p real — grok CLI solo tiene dos modos: 480p/720p, no puede hacer 1080p, se debe usar la API de xAI (grok-imagine-video-1.5 soporta 1080p), material real o Sora/Veo/Kling/Seedance (ver broll SKILL ④); ③ Dirección del material: basándose en esto, el IA genera o pide al usuario/editor que busque. No asumas el modo de carga por defecto — en 0722-01, se asumió por defecto pantalla completa y se aplicó una proporción de aspecto única, lo que requirió dos rondas de retrabajo.

Renderizado paralelo de segmentos sin material (Regla de hierro para acelerar, Decisión del usuario 2026-07-24): Después de confirmar el modo de carga y la dirección del material, no esperes a que llegue el material. Renderiza primero todos los segmentos de MG puro que no dependen de materiales externos. Solo deja marcadores de posición para los segmentos que esperan B-roll/pantalla en pantalla. Cuando llegue el material, renderiza solo esos segmentos y únelos al video completo con splice (los segmentos renderizados se unen en un video completo en segundos, ver §6). Es decir: los segmentos con dependencia de material y los independientes están desacoplados. Mientras el usuario busca el material, la sesión principal renderiza todo lo que puede, maximizando el paralelismo.

3. Si el guión de la locución proviene de un video de referencia (transcripción/reelaboración), primero debes extraer una hoja de contacto del video original y alinearla segmento por segmento (ffmpeg, un fotograma cada 10-15s, compón una cuadrícula). Basa la decisión en el procesamiento real del video original, no te tomes libertades: las 8 desviaciones en el primer ensamblaje provinieron todas de no haber visto primero el video original.

2.5 Taller de Alineación de Segmentos (Decisión del usuario 2026-07-16; Añadido criterio de modo dual 2026-07-17)

Modo de I+D vs Modo de Producción (Decidido después de que el usuario pidiera acelerar, primer principio: si la gramática ya está sedimentada, no se debe volver a excavar arqueología):

• Modo de I+D (Flujo completo de esta sección: lectura intensiva de fotogramas → plan → verificación de múltiples rutas → revisión final segmento por segmento) solo se usa para segmentos que introducen un nuevo patrón de arreglo. Criterio: el arreglo principal de ese segmento no puede encontrar una gramática correspondiente en las reglas existentes de narrative/rhythm/infographic/specs. El modo de I+D se divide en dos rutas de método, A y B: si hay un video de referencia del que se pueden extraer fotogramas = I+D-A (Paso 2 de esta sección: leer fotogramas de referencia); hueco gramatical y sin video de referencia = I+D-B, cuyo método en sí está en references/rd-noref.md (generación de múltiples planes → panel de juicio para seleccionar el mejor → decisión del usuario → retroalimentación y escritura). El Paso 2 de esta sección no se aplica a I+D-B.
• Modo de Producción (Segmentos de patrón reutilizado): No pasa por el bucle segmento por segmento; en su lugar, sigue una topología por lotes de "fantástico paralelo de todos los segmentos + integración centralizada" (cinco fases, ver §2.5.1). Criterio inverso: el arreglo principal de todos los segmentos puede encontrar una gramática correspondiente en las reglas existentes. Si la tasa de rechazo por judge de un segmento aumenta = ese segmento en realidad contiene un nuevo patrón, se asciende individualmente al modo de I+D, sin perjudicar a los demás segmentos (umbral cuantitativo para la actualización: el mismo segmento es rechazado en la revisión por lotes ≥2 veces o el usuario retrabaja en la revisión final, ver §2.5.1 Fase 4).

Bucle del modo de I+D segmento por segmento:

1. Dividir segmento: Alinea con el video de referencia según el contenido y corta docenas de fragmentos (comenzando a nivel de capítulo, los segmentos problemáticos se refinan hasta el nivel de ritmo). Disciplina de paralelismo de múltiples sesiones (Instrucción del usuario 2026-07-17): Antes de comenzar a trabajar, lee la tabla de segmentos en assembly/<NombreDelVideo>/分段工坊/segments.md (ejemplo de este video: assembly/0715-01/分段工坊/segments.md) — no toques los segmentos que tienen marcadores de posición. Cuando comiences a trabajar, primero escribe una línea de marcador de posición (identificador de sesión + lista de alcance: qué bloques de archivos vas a modificar). Los comandos de renderizado/npm son seriales en todo el proyecto (error #23/#24). Antes de iniciar un renderizado, usa pgrep para verificar la escena. Si es la primera vez que un nuevo video entra en el taller, el archivo no existe: la sesión principal lo inicializa — mkdir -p assembly/<NombreDelVideo>/分段工坊/ y luego crea segments.md, siguiendo el formato de la tabla de segmentos de 0715-01 (una línea por segmento: Número de segmento | Rango de tiempo | Punto principal de empaquetado | Archivos de alcance | Estado de marcador de posición/reclamo). Crea la estructura antes de asignar trabajo; los subagentes solo reclaman, no crean nuevos.

2. Mirar la referencia (Alineación a nivel de palabra, Decisión del usuario 2026-07-16): Extrae fotogramas densos del video de referencia para ese segmento (un fotograma cada 0.5s). Cuando el texto dictado sea el mismo que el del video de referencia, usa los subtítulos incrustados del video de referencia como eje de alineación — cada fotograma tiene "lo que está diciendo", lo que permite reconstruir una tabla de ritmo a nivel de palabra de "qué palabra dice → qué MG aparece", y luego encontrar el punto de tiempo de la misma oración en nuestro SRT. La comparación debe implicar leer y entender cada fotograma (especificaciones de elementos, relaciones de vinculación, acciones de cesión). No te limites a mirar los nombres de archivo o las miniaturas. Primero determina "segmento de material real vs segmento HUD dibujado a mano" (ver broll.md esquema general), luego mide primero, escribe código después — mide la proporción de la pantalla, el tamaño de fuente y la posición de los elementos desde los fotogramas de referencia. Está prohibido hacer estimaciones visuales (lección seg01: la estimación visual = encogimiento sistemático de 0.4-0.7 veces). Produce el "Plan" para ese segmento (tabla de ritmo + diagnóstico de diferencias + método de cambio + captura de pantalla de comparación). Muéstralo al usuario para su confirmación antes de tocar el código.

3. Hacer: Los segmentos de material siguen el pipeline de recolección; los segmentos HUD se escriben según los valores medidos.

4. Renderizar ese segmento: --frames=a-b, produce el video en decenas de segundos. Antes de renderizar, elimina los productos antiguos para evitar la caché de ○.

5. Aceptación (Tres compuertas, a partir de 2026-07-16; 2026-07-27 se añadió una compuerta estática previa): ⓪ Compuerta de reutilización de la base (node scripts/check-scenes.mjs src/koubo/scenes-<NombreDelVideo>) — escanea estáticamente el directorio de escenas: design/motion con cero referencias, cero componentes de salida (useExit/Exit/ClearOut, motion §1 sev5) cada uno es FAIL. Las categorías de componentes son inferiores al nivel del número de segmentos (video corto <10 segmentos: 3 categorías / video largo: 5 categorías), la tasa de cobertura de salida <50%, el kit propio >150 líneas con cero referencias a motion, cada uno se reporta como WARN. Al final, imprime una lista de verificación (scroll numérico / caída de veredicto / pantalla limpia entre capítulos / si el vocabulario de animación es único). Estos cuatro elementos no se pueden detectar con un escaneo estático; debes ver el metraje continuo tú mismo. (Los umbrales se revisaron después de una revisión adversarial el 2026-07-27: la versión inicial "WARN para cero referencias a Breathe" se eliminó — entraba en conflicto directo con motion §9 "Los nuevos videos no deben tener Breathe". "Categorías de componentes <4 de una sola vez" se eliminó porque los videos cortos tienen naturalmente pocos tipos de componentes, se reemplazó por "< nivel del número de segmentos".)

   ...

[truncated for translation]