---
type: PLAN
asset_id: PLAN-EL-MediaFactory-Industrializacion-v01
version: v01
status: Active — ratificado por Victor (L3) 2026-06-15
owner: Victor Heredia
sherpa: Jay (SherpaX · Room Mejoras Fábrica)
ratificador: Victor Heredia
fecha_creacion: 2026-06-15
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-MediaFactory
proposito: >
  Plan de industrialización de la MediaFactory partiendo del motor de video ya probado
  (Caso 0, hoy en /ReinventaVideos) como materialización de su Track A — Video. Le da a la
  MediaFactory el Loop Contract y la nomenclatura anti-caos que le faltan, y destila de ese
  Caso 0 la MetaFactoría de Producción de Activos que luego estampa las demás líneas
  (carruseles, portadas, audio) — todas alimentando LoopXDG (Demand Gen). Branding como
  pista aparte de alto criterio.
relacionados: >
  XP-EL-MediaFactory-v01 · TP-EL-MediaFactory-Arranque-v01 · PP-EL-LoopX-MacroLoopX-Arquitectura-v01 ·
  DC-EL-LoopXVOX-LoopContract-v01 (precedente del patrón) · DC-EL-LoopX-XDocMaestro-HubSpoke-v01 ·
  FAC-EL-DemandGenPack-v01 · TP-RB-FabricaVideos-RoomMejoras-Kickoff-v01 (motor en /ReinventaVideos)
tags: [plan, mediafactory, track-video, industrializacion, loop-contract, nomenclatura, demand-gen, macroloopx, caso0]
---

# PLAN — Industrialización de la MediaFactory
## Del motor de video "Caso 0" a una línea gobernada que produce 100 piezas con la misma energía

> **Encuadre.** Este plan responde a tres preocupaciones de Victor: (1) esto debería ser una Factoría, idealmente con una metafactoría que la genere; (2) no debe llamarse "Fábrica-Videos-Rebelocity"; (3) guardar todo en carpetas únicas se vuelve caos con 100 videos. El diagnóstico de vault (Gate G0) muestra que **el ecosistema ya tiene las piezas para resolver las tres** — falta conectarlas e instanciarlas, no inventarlas.

---

## 0. Decisiones ya ratificadas (2026-06-15)

| Decisión | Resolución | Quién |
|---|---|---|
| Gate G0 (consultar vault antes de producir) | ✅ Hecho — base de este plan | Jay |
| Hogar de las líneas de producción | **Dentro de la MediaFactory existente** (no estructura nueva) | Victor |
| Identidad del motor de video | **Materialización de un Track de la MediaFactory** (sin marca propia) | Victor |
| Prioridad del sprint | **Construirlo bien, sin prisa** — gobernanza primero, motor después | Victor |
| PLAN ratificado | ✅ **Aprobado 2026-06-15** → status Active | Victor |
| 1ª serie de video real | **"La Magia de MasterPlaybooks"** (entidad MPX) — estrena la nomenclatura. Victor ajusta el script | Victor |

> Nota de reconciliación (§5): Victor eligió "Track B" para video, pero la fuente canónica (TP MediaFactory §5) define **Track A = VIDEO**. Este plan adopta **Track A = Video** y trata la confusión A/B como un defecto a corregir.

---

## 1. Diagnóstico Gate G0 — lo que ya existe y encaja

| Pieza existente | Estado | Rol en este plan |
|---|---|---|
| **BMF** (gobernanza: Registry, naming, capas L2/L3) | Operando | **ES la "metafactoría que genera factorías"**: MetaFactorías (MePB Type D, L2) → Factorías (`FAC-`, L3) → producción |
| **MediaFactory** (`PB-EL-MediaFactory`, 4 tracks) | 🟢 Operativo audio-first | El hogar. Su **Track A — Video estaba diferido "hasta tener stack de video"**: el motor de /ReinventaVideos llena ese hueco |
| **Factoría de VOX** (`DC-EL-LoopXVOX-LoopContract`) | 🟢 Caso 0 probado | **El precedente exacto**: industrializó la voz de Victor (Caso 0) en un Loop Contract de 10 elementos. Mismo molde para video |
| **MacroLoopX** (`PP-EL-LoopX-MacroLoopX-Arquitectura`) | 🟢 Ratificado 11-jun | Define dónde encaja todo: producción multimedia alimenta **LoopXDG (Demand Gen)** |
| **XDoc Maestro hub-spoke** (`DC-EL-LoopX-XDocMaestro-HubSpoke`) | 🟢 Active | **El anti-caos**: cada entidad (serie/pieza) un Maestro + naming + Registry |
| **Naming de activos multimedia** (TP MediaFactory **§6.3**) | 🟢 Ya escrito | La convención `SC-/WOI-/OUT-…Video…` **ya existe** — el motor simplemente no la usa |
| **Motor de video** (/ReinventaVideos, render en Mac) | 🟢 Loop 1 funcional | El **Caso 0** de Track A. Multimarca por perfiles, estilo bloqueado (stock + VOX + subtítulos) |

**Conclusión:** no falta construcción, falta **gobernanza que conecte**. La nomenclatura que se pide ya está redactada (§6.3); el motor probado ya existe; el patrón de industrialización ya se ejecutó una vez (VOX). Este plan los une.

---

## 2. La tesis (analogía con VOX)

> **El motor de video es a Track A lo que la voz de Victor fue a la Factoría de VOX: el Caso 0 probado.**

La Factoría de VOX no se diseñó en abstracto: se tomó un caso real probado (la voz de Victor) y se industrializó en un Loop Contract; el *modelo* de factoría de voces se gradúa a capa universal (MePB Type D) **tras ≥2 casos**. Se replica idéntico:

1. Formalizar el motor de video como **Track A — Video** de la MediaFactory, con su Loop Contract y su nomenclatura.
2. **Destilar de ese Caso 0** la MetaFactoría de Producción de Activos (el builder).
3. Con el builder probado, **estampar** las demás líneas (carruseles, portadas, audio) como instancias delgadas.

Esto respeta la regla BMF de *destilar del caso real* en vez de teorizar el builder primero.

---

## 3. Arquitectura objetivo

```
  CAPA GOBERNANZA            BMF (Registry · naming · MePB Type D · MetaFactoryBuilder)
                                        │  "la metafactoría que genera factorías"
  CAPA METAFACTORÍA (L2)     MetaFactoría de Producción de Activos  ← se DESTILA del Caso 0 video
                                        │  (blueprint: estaciones · naming · QA · multimarca · Loop Contract)
  CAPA FACTORÍA (L3)         MediaFactory  ──────────────────────────────────────────────
                              ├── Track A · VIDEO    ← Caso 0 (motor /ReinventaVideos)  ⭐ primero
                              ├── Track B · AUDIO    ← consume VOX (LoopXVOX, upstream)
                              ├── Track C · POSTS/CARRUSELES
                              ├── Track A-visual · PORTADAS (nueva línea visual)
                              └── (pista aparte) · BRANDING — alto criterio, no en serie
                                        │
  CAPA PRODUCCIÓN            Outputs gobernados (XDoc Maestro por serie + naming §6.3 + Registry)
                                        │
  ORQUESTACIÓN              ──► LoopXDG (Demand Gen) ──► LoopXSA (Ventas) ──► …
```

**Invariantes respetados** (de `PP-EL-LoopX-MacroLoopX §4.3`): los *loops orquestan*, las *factorías producen*; nunca se suelda el motor a un loop; VOX queda upstream (produce el activo de voz que Track B consume) — interfaz, no soldadura.

---

## 4. El sistema anti-caos (la nomenclatura) — núcleo del plan

El problema "100 videos = caos" se resuelve con tres capas que **ya están diseñadas en el ecosistema**; el trabajo es *adoptarlas en el motor*:

### 4.1 Naming de outputs (TP MediaFactory §6.3 — ya canónico)

| Tipo | Nomenclatura BMF | Ejemplo |
|---|---|---|
| Guion de video | `SC-[ENT]-[Proyecto]-[Tema]-v01.md` | `SC-MPX-MagiaMPI-Intro-v01.md` |
| Work-in-progress | `WOI-[ENT]-[Proyecto]-Video-[Tema]-v01.md` | `WOI-MPX-MagiaMPI-Escena1-v01.md` |
| Output publicado | `OUT-[ENT]-[Proyecto]-Video-[Tema]-v01.mp4` | `OUT-MPX-MagiaMPI-Promo-v01.mp4` |

> Hoy los outputs viven como `videos-finales/…-stock-masterplaybooks.mp4` — sin entidad, sin tema, sin versión gobernada. La adopción de §6.3 es el cambio de mayor impacto inmediato.

### 4.2 XDoc Maestro por serie/pieza (patrón hub-spoke)

Cada **serie o pieza recurrente** de video = una entidad con su Maestro (`XD-[ENT]-PRD-[Serie]-Master-v01`), que concentra: identidad, marca, estado, links a guion/escenas/outputs/versiones, bitácora. El Maestro es la fuente de verdad; las carpetas son solo almacenamiento. Así, con 100 videos, **se navega por Maestros y Registry, no por carpetas sueltas**.

### 4.3 Estructura física y registro

- **Gobernanza** (Maestros, guiones canónicos, Loop Contract, este plan) → **vault** `PB-EL-MediaFactory`.
- **Motor** (código, render, assets pesados) → se queda en **/ReinventaVideos** (render corre en el Mac; el sandbox bloquea ElevenLabs/Pexels — separación motor/gobernanza intencional).
- Cada activo canónico se **registra en el Registry** (`CP-XX-IntelliBanks-Registry`) — deja de haber activos huérfanos.

---

## 5. Defecto detectado — inconsistencia Track A/B (item LoopXKZ)

El **XP** de MediaFactory (§2, diagrama) rotula *Track A = Audio, Track B = Video*; el **TP** (§5, definiciones con pipelines) define *Track A = VIDEO, Track B = AUDIO*. Es exactamente el tipo de desorden que preocupa a Victor.

**Resolución propuesta:** la fuente con definición operativa detallada (pipelines, formatos) es el TP → **se fija Track A = VIDEO, Track B = AUDIO** y se corrige el diagrama del XP. Se documenta como caso en LabPraxis (aprendizaje de LoopXKZ: las dos fuentes de una factoría deben tener un solo mapa de tracks).

---

## 6. Mapeo de las líneas que pide Victor

| Línea solicitada | Dónde cae | ¿Net-new? |
|---|---|---|
| **Audios voz Victor + otros VOX** | **LoopXVOX** (destila la voz, upstream) + **Track B Audio** (produce la pieza) | No — operar lo existente |
| **Carruseles** | **Track C — Posts/Carruseles** (ya declarado, pipeline `CAROUSEL-1`) | No — activar el track |
| **Portadas MasterPlaybooks** | Nueva **línea visual** dentro de MediaFactory (instancia del builder) | Sí — línea nueva delgada |
| **Paquetes de branding (brand book)** | **Pista aparte de alto criterio** — design system, decisión humana obligatoria | Sí — pero NO en serie (ver §8) |

Todas convergen en **LoopXDG**, exactamente como planteó Victor. ✅

---

## 7. Plan por fases (gobernanza primero · sin prisa)

| Fase | Objetivo | Entregables | Gate de salida |
|---|---|---|---|
| **F0 · Reconciliar** | Cerrar inconsistencias y fijar base | Fijar A=Video (corregir XP) · caso LabPraxis · este PLAN ratificado | Victor ratifica el PLAN |
| **F1 · Caso 0 → Track A** | Formalizar el motor de video como Track A gobernado | Loop Contract de la MediaFactory (harness 10 elementos, patrón VOX) · adopción de naming §6.3 en el motor · 1er XDoc Maestro de serie · registro en Registry | El motor produce 1 video con naming + Maestro correctos |
| **F2 · Destilar MetaFactoría** | Sacar el builder del Caso 0 probado | `MePB-…-ProduccionDeActivos` (estaciones, naming, QA, multimarca, plantilla Loop Contract) | Blueprint ratificado |
| **F3 · Estampar líneas** | Instanciar carruseles, portadas, audio | `FAC-` delgadas por línea, cada una hereda el blueprint | Cada línea produce su 1ª pieza gobernada |
| **F4 · Branding (especial)** | Pista de alto criterio | Spec de brand-kit como design system (no línea autónoma) | — |
| **Continuo · Afinar motor** | Mejoras del motor de video (Loop 1.1) | worker desatendido, publicación, QC stock v2, etc. (frentes del kickoff) | Producción en serie |

> El orden honra la indicación de Victor ("luego afinamos el video"): primero la arquitectura/gobernanza (F0–F3), el tuning del motor corre en paralelo/después como track continuo.

---

## 8. Riesgos y lo que NO se hace (recomendaciones)

- **No industrializar branding como línea en serie.** Un brand book / sistema de identidad es bajo volumen y alto criterio: va en *decisión humana obligatoria* (matriz de autonomía §4.2 del MacroLoopX), no en producción autónoma. Tratarlo como línea en serie degradaría la marca.
- **No migrar el código pesado al vault.** El render vive en el Mac por la restricción de red; mantener la separación motor (/ReinventaVideos) ↔ gobernanza (vault).
- **No crear la MetaFactoría en abstracto antes del Caso 0.** El patrón BMF (y el precedente VOX) exige destilar del caso real; diseñar el builder primero es el anti-patrón.
- **No proliferar factorías sueltas.** Una sola MediaFactory con tracks/instancias gobernadas, no 4–5 factorías independientes.
- **Higiene pendiente del motor** (del resumen del room): rotar keys (ElevenLabs/fal/Pexels), limpiar la marca de agua "NotebookLM" en `scene1.mp4`, cablear logo EmpowerLabs (placeholder). Entran como NEXTs de F1/continuo.

---

## 9. Gobernanza

- **Tripleta:** Owner Victor · Sherpa Jay · Ratificador Victor (L3).
- **Autonomía:** diseño de arquitectura = L3 (decide Victor). Operación por estación = autonomía graduada IA con ratificación por excepción.
- **Casa de gobernanza:** `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-EL-MediaFactory`. **Motor:** `/ReinventaVideos`. **Minuta semanal** en Reinventaverse (autorizada por el kickoff).

---

## 10. NEXTs

- [x] **Victor:** ratificar este PLAN (F0) — ✅ 2026-06-15.
- [x] **Victor:** decidir la 1ª serie de video real — ✅ "La Magia de MasterPlaybooks".
- [x] **Jay:** fijar Track A = Video y corregir el XP (F0) — ✅ 2026-06-15.
- [x] **Jay:** redactar el Loop Contract de la MediaFactory (harness de 10, patrón VOX) — ✅ `DC-EL-LoopXMED-LoopContract-v01`.
- [x] **Jay:** crear 1er XDoc Maestro de serie (`XD-MPX-PRD-LaMagia-Master-v01`) — ✅ F1.
- [ ] **Jay:** documentar el caso A/B en LabPraxis (LoopXKZ) — pendiente.
- [ ] **Victor:** terminar de ajustar el script de "La Magia de MasterPlaybooks".
- [ ] **Jay:** adoptar naming §6.3 en los outputs del motor (renombrar `videos-finales/`) — F1 continuo.
- [ ] **Jay:** destilar `MePB-…-ProduccionDeActivos` del Caso 0 (F2) — tras 1ª pieza gobernada.

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-06-15 | Creación. Plan de industrialización de la MediaFactory: motor de video = Caso 0 de Track A; Loop Contract + nomenclatura (§6.3 + XDoc Maestro); MetaFactoría destilada del Caso 0; mapeo de líneas (video/carruseles/portadas/audio→LoopXDG, branding aparte); plan en 5 fases; reconciliación del defecto A/B XP-TP. Draft — pendiente ratificación Victor (L3). |
| v01 | 2026-06-15 | **Ratificado por Victor (L3)** → Active. 1ª serie = "La Magia de MasterPlaybooks". F0 ejecutado (XP corregido a A=Video). F1 ejecutado: Loop Contract `DC-EL-LoopXMED-LoopContract-v01` + XDoc Maestro `XD-MPX-PRD-LaMagia-Master-v01`. |