Plan de trabajo CDE

Plan

Arquitectura mínima para publicar shorts con Nextcloud, NocoDB y n8n sin sobrecargar la operación.

Estrategia de comunicación multicanal

Fecha: 2026-03-24
Estado: arquitectura mínima operativa
Alcance inmediato: YouTube Shorts
Expansión prevista: TikTok, Instagram Reels, Telegram

Resumen ejecutivo

La propuesta inicial se simplifica de forma deliberada.

La prioridad no es modelar todo el ecosistema editorial, sino disponer de un flujo manejable para una sola persona que permita:

  • subir un short terminado a Nextcloud
  • registrar una tarea de publicación en NocoDB
  • ejecutar la publicación desde n8n
  • guardar el resultado de forma trazable

La fase actual deja fuera la automatización completa de:

  • lesson_cde
  • sincronización YouTube + iVoox
  • campañas complejas
  • tablas relacionales auxiliares que obliguen a rellenar demasiados metadatos

Principio rector

Si el sistema requiere más tiempo de mantenimiento que la publicación manual, el sistema está mal dimensionado.

Por tanto, la fase 1 se diseña con esta regla:

  • una pieza lista para publicar debe poder registrarse en una sola fila operativa

Decisiones adoptadas

  • Nextcloud será la fuente única de archivos para automatizaciones.
  • NocoDB se usará como cola de publicaciones, no como ERP editorial.
  • n8n leerá una tarea lista, descargará el vídeo desde Nextcloud por WebDAV y ejecutará la publicación.
  • El primer canal objetivo es YouTube Shorts.
  • TikTok e Instagram Reels reutilizarán la misma arquitectura cuando el flujo de YouTube Shorts funcione bien.
  • La automatización de lesson_cde queda fuera de esta fase.

Arquitectura mínima

1. Almacenamiento de archivos

Todos los vídeos y variantes viven en Nextcloud.

Base actual:

  • /Volumes/E/Nextcloud/espacio-sutil

Referencia remota para automatización:

  • https://materiales.e451.net/remote.php/dav/files/admin/

Regla:

  • n8n no debe depender de rutas locales del Mac
  • n8n debe trabajar con URLs WebDAV autenticadas

2. Cola de publicación

Se reutiliza la tabla distribution_tasks como cola mínima de publicaciones por canal.

En esta fase:

  • una fila = una publicación en un canal
  • no hace falta pasar por campaigns, templates, source_items, assets ni content_units

3. Orquestación

n8n hará solo estas funciones:

  1. leer tareas con channel = youtube_short
  2. filtrar por state = ready
  3. descargar el vídeo desde asset_url usando WebDAV
  4. publicar o preparar la publicación en YouTube
  5. escribir de vuelta el resultado en NocoDB

Tabla operativa mínima

Tabla distribution_tasks

Uso: cola de publicaciones por canal.

Campos que sí se usan en la fase 1:

CampoUso
target_accountcuenta o canal destino, por ejemplo youtube:EspacioSutil
channelcanal de publicación
publish_modeassisted mientras el flujo no esté consolidado
stateestado operativo de la tarea
scheduled_atprogramación opcional
published_atfecha real de publicación
asset_urlURL WebDAV del vídeo a publicar
caption_texttexto final de la publicación
hashtagslista de hashtags como texto
external_post_idid devuelto por la plataforma
external_post_urlURL final de la publicación
error_lastúltimo error de ejecución

Campos eliminados en la simplificación:

  • relaciones con otras tablas
  • plantillas obligatorias
  • aprobaciones binarias por fila

Solo se reintroducirán si reducen trabajo real.

Estados operativos

Aunque la tabla permita más valores, la fase 1 trabajará con solo estos:

  • draft: tarea en edición
  • ready: lista para ser procesada por n8n
  • published: publicación completada
  • failed: error en automatización o publicación

Estructura de directorios en Nextcloud

Para shorts:

espacio-sutil/
  editorial/
    content-units/
      short-campaign/
        2026/
          2026-03-primer-short-cde/
            master/
            channel/
              telegram/
              instagram/
              tiktok/
              youtube-shorts/
            copy/

Notas:

  • master/ contiene el vídeo principal
  • cada subcarpeta de channel/ solo se usa si existe una adaptación específica
  • si un canal no tiene adaptación específica, n8n usa el master

Regla de fallback de archivos

Orden de resolución por canal:

  1. buscar archivo específico del canal
  2. si no existe, usar el archivo en master/

Esto evita tener que generar tres variantes distintas cuando el mismo vídeo sirve para YouTube Shorts, TikTok e Instagram Reels.

Ejemplo real de tarea

Short actual:

  • pieza: marco_0001
  • canal: youtube_short
  • cuenta: youtube:EspacioSutil
  • modo: assisted
  • destino web: hub del curso

Ejemplo de caption_text:

Descubre el Curso de desarrollo espiritual:
https://espaciosutil.org/curso-de-desarrollo-espiritual/?utm_source=youtube&utm_medium=organic_social&utm_campaign=cde_launch_wave1&utm_content=marco_0001

Ejemplo de asset_url:

https://materiales.e451.net/remote.php/dav/files/admin/espacio-sutil/editorial/content-units/short-campaign/2026/2026-03-primer-short-cde/master/cde-centered-glow-sequence.mp4

Qué queda fuera ahora

lesson_cde

No entra en esta fase.

Motivo:

  • requiere coordinar Bunny, WordPress y varios artefactos asociados
  • no es comparable al flujo simple de publicación de un short

episode_ivan

Se aplaza.

Motivo:

  • requiere reconciliar dos fuentes distintas, YouTube e iVoox
  • puede resolverse después con una automatización específica para avisos y distribución

Roadmap por fases

Fase 1

  • una sola tabla operativa en NocoDB
  • un solo canal: YouTube Shorts
  • archivos en Nextcloud
  • n8n publica y devuelve estado

Fase 2

  • duplicar el mismo patrón para TikTok
  • duplicar el mismo patrón para Instagram Reels
  • mantener la misma estructura de datos

Fase 3

  • valorar si compensa reintroducir:
    • plantillas de copy
    • registro editorial de piezas
    • inventario separado de assets
    • flujos específicos para lesson_cde o episode_ivan

Solo se recuperará complejidad si reduce trabajo real.

Conclusión

La arquitectura correcta para la fase actual no es la más completa, sino la más ligera que permita publicar de forma repetible.

La unidad operativa deja de ser la “pieza editorial completa” y pasa a ser:

  • una tarea de publicación por canal

Ese cambio reduce fricción, mantiene trazabilidad y permite automatizar sin convertir el sistema en un cuello de botella.