D'Lyra Studio · Command Center interno
Índice vivo de los hubs publicados. Cada cifra sale de contar elementos en el archivo del hub, no de una estimación. Lo que no se puede contar aparece como — y está listado abajo, en pendiente de conectar.
Esta página lista todos los clientes. No se comparte con ningún cliente: a cada uno se le manda el link de su hub, nunca este índice. Hoy las rutas son públicas y adivinables — mientras Cloudflare Access no esté activo, el único control es no repartir este link.
Los hubs ordenados por el mes que cubren. Los meses sin hub aparecen igual, marcados con línea punteada: un hueco visible vale más que un hueco tapado.
/ → este índice (interno)
/{cliente}/ → hub del mes activo
/{cliente}/{AAAA-MM}/ → un mes concreto
/r.html → rescate de feedback
El mes va en formato AAAA-MM, nunca «mes 2» ni «mes 3». Con la fecha la
ruta se adivina sin preguntar y ordena sola; con «mes 2» hay que ir a mirar a qué corresponde.
Misma convención que las carpetas del repo: clients/{cliente}/contenido/{AAAA-MM}/.
Verificado hoy: /ingrid/ y /ingrid/2026-08/ son el mismo archivo
(md5 idéntico), igual que /medplan/ y /medplan/2026-08/. La raíz del
cliente es una copia del mes activo, no un redirect — al cambiar de mes hay que copiar de nuevo.
Esto todavía no tiene datos en vivo. Está aquí y no escondido porque un panel que inventa una cifra es peor que uno que la deja en blanco. Cada punto lleva la evidencia de cómo se midió.
No hay likes, alcance ni guardados para ninguna pieza de ningún hub. No es que falte pintarlos: la fuente devuelve vacío. Antes de construir nada hay que preguntarle al proveedor si es cosa del plan contratado o de una opción sin activar — es una pregunta comercial, no trabajo de ingeniería. Y aunque se active, TikTok queda fuera: su documentación solo cubre X, Instagram, Facebook, Threads y Bluesky.
medido 2026-08-08 · list_top_posts → vacío (todas las plataformas y también acotado a Instagram abr–jun, donde sí hay posts) · get_post_analytics sobre un post publicado real → «Not found» · registrado en docs/DISENO_HUB_CLIENTE_2026-08-08.md §10.2
Los hubs sí pintan un estado por pieza, pero es una marca puesta a mano y
guardada en el navegador de quien la marcó — no un registro de publicación. En
/medplan/2026-08/ el mapa de overrides está literalmente vacío
(PUBLISHED_OVERRIDES = {}) y el resto vive en localStorage. Nadie más ve esas
marcas, y se pierden al limpiar el navegador. El registro real existe en Blotato
(state: programado · publicado + link · fallido + error), pero todavía no
entra al hub.
contado en el build: medplan/2026-08/index.html:1382 · historial de Blotato cortado el 10 de mayo de 2026 — si una pieza se publica por fuera, Blotato no la conoce (§10.3)
feedback-capture.js ya está publicado en la raíz del sitio y probado de
punta a punta, pero ningún hub lo carga. Los comentarios que escriba un cliente hoy
se guardan en su localStorage y no salen de ahí: no llegan al Sheet ni al
correo. Es el paso 1 del plan de montaje y el que no depende de nada — se puede hacer hoy.
contado en el build: 0 de 4 hubs referencian
feedback-capture.js · 0 hubs contienen una URL de webhook · el único
archivo con la llamada real es r.html (el rescate)
Cualquiera que escriba /ingrid/ ve el calendario completo de Ingrid.
Separar «hub del cliente» de «panel interno» no se resuelve ocultando secciones: si el
dato está en el HTML que recibe el cliente, el cliente lo tiene. Son dos builds distintos,
no dos pestañas — y hasta que eso exista, este índice no se comparte.
diseño acordado en docs/DISENO_HUB_CLIENTE_2026-08-08.md §3 y §4 · pasos 2 y 3 del orden de montaje (§7)
No todas las piezas dicen en qué punto están. Se cuentan y se muestran como «sin estado» en vez de asumir que están listas: 6 de 16 en MedPlan agosto y 15 de 38 en MedPlan abril. En los hubs de Ingrid el estado es del día, no de la pieza, así que no es comparable.
contado en el array CONTENT de
medplan/2026-08/index.html y medplan/2026-04/index.html