kaustubhupadhyaya/phone-reel-pipeline

¿Qué hace phone-reel-pipeline?

El pipeline de extremo a extremo desde Android hasta Instagram-reel. El teléfono proporciona el metraje (y opcionalmente inspiración de tendencias); el PC realiza toda la edición; el teléfono recibe el reel terminado para que el usuario lo publique manualmente. Esta skill orquesta a sus hermanas — no contiene scripts propios ni duplica su lógica. Una sola llamada ejecuta toda la cadena: el agente desbloquea el teléfono por sí mismo (PIN de la bóveda, sin que el usuario toque el teléfono) y navega la app Edits por sí mismo cuando se desea inspiración.

Skills hermanas en este repositorio — phone-reel-pipeline redirige a ellas, no las reimplementes: phone-media-bridge gestiona la conexión del dispositivo más desbloqueo de pantalla de bloqueo y extracción/envío de medios, ig-edits-inspiration gestiona la inspiración de la app Edits (captura de solo lectura más navegación autoguiada en un teléfono desbloqueado), reel-maker gestiona la construcción del reel en PC (y a su vez delega en clip-picker y video-tool-router — nunca llames a esos dos directamente desde aquí). Lee el SKILL.md de la hermana en su ruta relativa antes de cada fase; sus documentos son autoritativos para flags, rutas y problemas comunes.

Cuándo usar

Disparadores: "reel de extremo a extremo desde el teléfono", "haz un reel con mi metraje del teléfono", "teléfono a reel", "extrae del teléfono y haz un reel", o cualquier tarea que abarque dispositivo → PC → dispositivo en una sola ejecución.

NO para:

• Edición solo en PC con metraje ya en disco y sin teléfono involucrado → invoca reel-maker directamente.
• Solo inspiración ("qué está de moda", "hoja de ruta para esta edición", sin construir aún) → invoca ig-edits-inspiration directamente.
• Publicación → siempre el usuario, en el teléfono, manualmente. Ninguna skill en este repositorio publica, programa o sube nada — la auto-publicación fue explícitamente rechazada.

Flujo de trabajo

Fase 0 — Verificación del dispositivo + desbloqueo

Ejecuta adb devices -l. Localiza adb mediante la cadena de scripts del puente (flag --adb, variable de entorno ADB, PATH, luego el fallback de WinGet platform-tools). Si la lista de dispositivos está vacía, DETENTE e imprime esta lista de verificación para el usuario:

1. Inalámbrico: teléfono en la misma red Wi-Fi que el PC, depuración inalámbrica ACTIVADA (vuelve a emparejar con código + adb connect <ip>:<port> si el enlace se perdió).
2. USB: cable con capacidad de datos (no solo de carga), modo Transferencia de archivos (MTP), depuración USB habilitada, solicitud de huella digital RSA aceptada en el teléfono.

Si el dispositivo aparece como unauthorized, no continúes — pide al usuario que acepte la solicitud RSA en el teléfono, luego vuelve a ejecutar adb devices -l. Solo continúa una vez que el dispositivo aparezca como device. Luego desbloquea para la ejecución autónoma (sin necesidad de que el usuario toque el teléfono):

C:\Python314\python.exe %USERPROFILE%\GitHub\editor-pack\skills\phone-media-bridge\scripts\unlock.py

ALREADY_UNLOCKED → continúa. VAULT_ENTRY_MISSING → recoge phone-1:password mediante la ventana emergente de la bóveda (python "%USERPROFILE%\.agents\skills\secure-vault\vault.py" gui --request "phone-1:password"), luego vuelve a ejecutar. Reglas completas en phone-media-bridge Fase 0b.

Fase 1 — Inspiración (OPCIONAL, solo si el usuario quiere ediciones guiadas por tendencias)

Haz una pregunta: ¿guiado por tendencias (inspiración de Edits) o construcción directa (enlace de referencia o libre)? Si el usuario quiere guía de tendencias, pasa el control a ig-edits-inspiration: captura desde la app Edits (se prefiere captura de solo lectura; se permite navegación autoguiada de la UI en el teléfono desbloqueado según su doctrina) y devuelve una receta con forma de reel-maker. Esa receta se convierte en la especificación de construcción para la Fase 3. Pedir al usuario que navegue Edits por sí mismo es la alternativa de ruta rápida, no un requisito: el agente conduce cuando el usuario no lo ha hecho. Si el usuario omite la inspiración, ve directamente a la Fase 2 — la Fase 1 de reel-maker ya acepta un enlace de referencia, por lo que cualquier enlace que el usuario haya proporcionado viaja con el traspaso sin cambios.

Fase 2 — Extracción de medios

Pasa el control a phone-media-bridge: ejecuta su paso de inventario, luego muestra al usuario un resumen compacto por carpeta (nombre de la carpeta, cantidad de clips, tamaño total — no un volcado completo de archivos) y haz UNA pregunta (selección múltiple) sobre qué carpetas/clips extraer. Luego ejecuta su paso de extracción. El metraje extraído llega a la unión skills\phone-media-bridge\scripts\phone_pull (físicamente en D:\EditorPackArchive). El metraje permanece en D: — los editores leen desde allí, nunca lo copien a C:. Seguro ante reinicios: si el teléfono se desconecta durante la extracción, vuelve a ejecutar la extracción; consulta Problemas comunes.

Fase 3 — Construcción en PC

Invoca el flujo de reel-maker con la receta de la Fase 1 (o el enlace de referencia) más la carpeta de metraje de la Fase 2. reel-maker delega en clip-picker + video-tool-router por sí mismo — no dupliques ese enrutamiento aquí. Dos cosas a transmitir explícitamente: (a) el metraje del teléfono suele ser HEVC/HDR, por lo que se aplica la protección HLG de 10 bits de video-tool-router (mapeo de tonos antes de la gradación/inserción de subtítulos, o los colores se desvanecen); (b) la decodificación HEVC es lenta, por lo que se espera que la Fase 3 domine el tiempo de ejecución (consulta los problemas comunes de clip-picker).

Fase 4 — Envío de vuelta (PUERTA DE APROBACIÓN)

REGLAS ESTRICTAS: NUNCA envíes nada al teléfono sin la aprobación explícita del usuario para ese archivo exacto en esta ejecución. Terminar la Fase 3 NO implica permiso para enviar. Detente al final de la Fase 3 e informa las rutas locales del PC, la duración y el tamaño; pregunta "¿enviar al teléfono?" y continúa solo si la respuesta es sí. Una instrucción genérica "haz reels" nunca cuenta como aprobación de envío.

Una vez aprobado, pasa el control a phone-media-bridge paso de envío (push_reel.py): envía el reel_<nombre>_vN.mp4 terminado a /sdcard/Movies/Reels en el teléfono. Verifica que el archivo exista en el dispositivo (adb shell ls) e informa su tamaño en bytes comparado con la copia en PC.

Fase 5 — Entrega (el usuario publica)

Ejecuta el paso de phone-media-bridge que abre Instagram en el teléfono (push_reel.py --open-app). Luego DETENTE: el USUARIO publica, manualmente, en la app de Instagram. NUNCA auto-publicación — explícitamente rechazada. Informa: la ruta del reel (ruta en el teléfono + ruta en PC), el número de versión y una breve lista de qué verificar antes de publicar (subtítulos legibles, audio presente, relación de aspecto correcta).

Salida

• reel_<nombre>_vN.mp4 en el teléfono (/sdcard/Movies/Reels/) + la copia en PC guardada en la carpeta del proyecto (versionada; nunca sobrescribe v1).
• Un informe de estado de extremo a extremo: aprobado / omitido / fallido por fase, tiempos de reloj de pared por fase, qué skill hermana manejó cada fase y advertencias honestas (ver más abajo). Ejemplo de formato: Fase 0 aprobada (dispositivo <serial>, desbloqueado mediante bóveda, 5s) → Fase 1 omitida (usuario eligió construcción directa) → Fase 2 aprobada (3 clips, 1.2 GB, 4 min) → Fase 3 aprobada (reel_<nombre>_v1.mp4, 22 min) → Fase 4 aprobada (envío verificado, tamaños coinciden) → Fase 5 entregada (Instagram abierto, usuario debe publicar).

Problemas comunes

• Unión faltante después de un clonado nuevo: skills\phone-media-bridge\scripts\phone_pull es una unión a D:\EditorPackArchive y no sobrevive a un clonado nuevo — vuelve a crearla según la documentación de phone-media-bridge antes de la Fase 2.
• Teléfono desconectado durante la ejecución: las extracciones son seguras ante reinicios (vuelve a ejecutar el paso de extracción); los envíos no lo son — vuelve a ejecutar push_reel.py y vuelve a verificar con adb shell ls.
• Teléfono que se vuelve a bloquear durante la ejecución: unlock.py establece permanecer despierto + tiempo de espera de 30 minutos, pero un reinicio o bloqueo manual reactiva la pantalla de bloqueo — vuelve a ejecutar unlock.py (el PIN permanece en la bóveda, no se necesita acción del usuario) y continúa.
• La decodificación HEVC es lenta (problema común de clip-picker): las hojas de contacto y la puntuación de movimiento sobre metraje del teléfono toman más tiempo que sobre H.264 — dilo desde el principio, no reduzcas el muestreo para compensar.
• Nunca auto-publiques: sin automatización de UI del flujo de publicación de Instagram, sin programación, sin subidas. Abrir la app para el usuario es el último paso automatizado.

Reglas de informe honesto

• Informa lo que realmente se verificó vs lo que se asumió, por fase: número de serie del dispositivo visto en adb devices -l (no "teléfono conectado"), desbloqueo verificado mediante dumpsys (no "teléfono abierto"), recuentos de bytes de extracción coincidentes (no "archivos copiados"), envío verificado con adb shell ls + coincidencia de tamaño, Instagram abierto (no "reel publicado").
• Si una fase fue omitida (por ejemplo, sin inspiración), dilo explícitamente — nunca impliques que su salida existe.
• Honestidad temporal: informa el tiempo de reloj de pared medido por fase; el tiempo de transcodificación/puntuación HEVC es trabajo real, no sobrecarga para ocultar.
• Señala las advertencias de calidad en lugar de enviarlas en silencio: selecciones temblorosas, HDR desvaído, límites de republicación con audio prestado (se aplican las reglas de la Fase 5 de reel-maker).