senzapaura_es/docs/plan-nueva-administracion-2026-09-11.md

Diseño de una nueva administración para Senza Paura

Fecha: 11 de septiembre de 2026. Estado: aplicación nueva implementada en entorno local de pruebas. La puesta en producción sigue pendiente. Véase el documento de implementación de Estudio.

1. Punto de partida

Diseñar una aplicación administrativa nueva desde las tareas de quien mantiene Senza Paura. Su navegación, entidades, componentes y servicios se definirán expresamente para ese propósito. El panel actual se utilizará como inventario de datos y referencia de problemas; su organización y sus formularios no serán la base del nuevo diseño.

El alcance incluye catálogo musical, contenido editorial, taller, medios, ventas y acceso. Las tareas prioritarias son crear y publicar música, organizar lanzamientos y mantener artistas. Una persona debe poder completar esas tareas sin conocer tablas, scripts ni dependencias internas.

Se conservarán los contenidos, archivos, identidades, compras y referencias históricas. También las garantías necesarias de autorización, integridad y entrega de compras. El código existente solo se reutilizará cuando encaje en los contratos nuevos y supere sus pruebas; no habrá obligación de conservar el esquema actual si dificulta representar correctamente el dominio.

2. Definir primero el producto

Antes de construir pantallas se prepararán tres entregables:

1. Mapa de tareas: crear un artista; preparar una canción; añadir una versión; montar un lanzamiento; publicar contenido; resolver un pedido; gestionar un acceso.
2. Diccionario de entidades: significado, relaciones, datos mínimos y ciclo de vida de cada elemento. Diferenciar conceptos musicales, editoriales y comerciales.
3. Prototipo navegable: listados, fichas y altas completas, incluyendo catálogo vacío, datos incompletos, relaciones inexistentes y fallos de guardado.

El modelo y las pantallas se contrastarán con casos reales: una canción suelta, un álbum con varios artistas, dos versiones con distinta letra, una grabación incluida en dos lanzamientos y una canción retirada que ya tiene compradores.

3. Modelo conceptual propuesto

La propuesta distingue la canción de sus grabaciones y la grabación de los archivos que permiten escucharla. Esta separación debe permitir representar versiones con estilo, letra, idioma e intérpretes distintos.

Entidad	Responsabilidad	Relaciones
Canción	Identidad del tema y agrupación de sus grabaciones.	Una o varias grabaciones, una elegida como principal para la presentación, referencias editoriales.
Grabación o versión musical	Una interpretación concreta: estudio, acústica, maqueta, otro idioma, etc.	Canción, intérpretes, créditos, letra, idioma, estilo, imágenes y audios propios.
Lanzamiento	Álbum, EP, single o colección, con portada y datos de edición.	Lista ordenada de pistas.
Pista de lanzamiento	Ubicación de una grabación en un lanzamiento.	Lanzamiento, grabación y posición. Permite reutilizar una grabación sin duplicarla.
Persona	Identidad con uno o varios tipos: Artista, Letrista, Compositor, Músico o Artista virtual; se conserva Productor para créditos existentes.	Interpretación, autoría, composición, producción, biografía e imágenes.
Medio	Archivo con metadatos, estado y usos conocidos.	Representaciones de audio, portadas, fotografías y otros recursos.

flowchart LR
    C[Canción] --> G[Grabaciones y versiones]
    A[Personas con tipos múltiples] --> CR[Créditos de interpretación, letra y composición]
    CR --> G
    L[Lanzamiento] --> P[Pistas ordenadas]
    P --> G
    G --> M[Máster, escucha y descarga]

El diagrama representa relaciones, no una estructura obligatoria del menú. Los artistas se relacionan con las grabaciones mediante créditos; un disco no tiene por qué pertenecer a un único artista.

Al crear otra versión se podrá copiar una selección explícita de datos. Sus cambios posteriores serán independientes. Una copia MP3 o de escucha pertenece a la misma grabación y no aparecerá como otra versión musical.

Los estilos del catálogo y los géneros del taller tendrán ámbitos y nombres inequívocos. La clasificación musical podrá variar entre grabaciones de una misma canción.

La propuesta de persistencia se diseñará después de validar estos conceptos con el prototipo. La migración deberá mapear cada fila actual a su destino y conservar IDs públicos o equivalencias estables. La compra seguirá dando acceso a la canción y a las versiones que correspondan según las reglas existentes; el rediseño administrativo no cambiará por sí solo las condiciones comerciales.

4. Arquitectura de información

Barra lateral agrupada en escritorio y menú desplegable en móvil. Cabecera con búsqueda, creación, acceso al sitio y cuenta. El contexto de una ficha se indica mediante ruta de navegación, título y estado.

Área	Secciones
Inicio	Trabajo reciente y pendientes accionables.
Música	Canciones, Lanzamientos, Personas y Clasificación.
Contenido	Blog, Páginas, Textos legales.
Taller	Capítulos, Géneros musicales, Glosario, Prompts.
Ventas y acceso	Pedidos, Cuentas, Suscripciones.
Medios	Biblioteca de imágenes y audio, Procesamiento.
Configuración	Modelos de IA, Vocabularios auxiliares, Redirecciones, Actividad y Diagnóstico.

Las versiones se gestionan principalmente desde su canción; las pistas, desde su lanzamiento; los créditos, desde la entidad acreditada. Las tablas auxiliares no se convierten automáticamente en entradas del menú.

El inicio tendrá accesos como «Nueva canción», «Nuevo lanzamiento» y «Nueva persona», borradores recientes y pendientes con destino concreto: «Añadir el audio de…» o «Revisar el pago de…». Los diagnósticos técnicos tendrán su propio lugar.

5. Una experiencia consistente

Listados

• Título claro y botón visible para crear la entidad correspondiente.
• Búsqueda, filtros y paginación en servidor, conservados en la URL.
• Columnas adaptadas a cada entidad: identificación, relaciones relevantes, estado y última modificación.
• Filtros musicales por artista, lanzamiento, estilo, estado y tareas pendientes.
• Diferenciar una sección vacía de una búsqueda sin resultados; explicar cómo empezar.
• Acciones de fila reconocibles y retorno a la búsqueda anterior desde la ficha.

Fichas

• Resumen de identidad y relaciones, con enlaces para recorrerlas en ambas direcciones.
• Pestañas con URL propia y navegación por teclado.
• Campos esenciales primero; detalles técnicos y poco frecuentes en apartados secundarios.
• Guardado y errores coherentes, aviso de cambios pendientes y detección de conflictos entre sesiones.
• Estados con texto e icono, además de color.
• Retirar y eliminar con significado y efectos diferentes; conservar registros necesarios para compras e historial.

Diseño visual

Sistema visual propio para administración: tipografía legible, jerarquía clara, superficies sobrias, densidad adecuada para tablas y espacio suficiente para editar. Marca y acentos conectados con Senza Paura. Componentes creados para trabajar con formularios, relaciones y estados, con etiquetas visibles y foco reconocible.

6. Flujos principales

Crear una canción

1. Elegir «Nueva canción» e introducir el título. Crear un borrador persistido con su grabación principal en preparación.
2. Completar los datos básicos y la clasificación. Las referencias incompletas pueden seguir pendientes mientras sea borrador.
3. Añadir intérpretes mediante un selector con búsqueda. Si falta un artista, darlo de alta en un formulario breve y continuar con él seleccionado.
4. Añadir audio, imágenes, letra y créditos desde la propia ficha, en el orden elegido.
5. Incorporarla a un lanzamiento existente o crear uno desde el mismo recorrido.
6. Consultar lo que falta, abrir la vista previa y publicar cuando se cumplan las reglas.

No se exigirá subir audio para poder guardar el primer borrador. El estado y los pendientes harán explícito qué queda por completar.

Crear un lanzamiento

Crear el borrador, seleccionar el tipo, completar portada y datos de edición, y montar las pistas. Cada pista permite elegir una grabación existente o crear una canción. Reordenar tendrá botones accesibles además del arrastre. La relación de pistas permitirá incluir una grabación en otro lanzamiento sin moverla del anterior ni duplicar su audio.

Añadir una versión

Desde la canción, elegir «Añadir versión», darle un nombre y seleccionar qué datos copiar. Se abre una ficha completa de la nueva grabación con contexto visible de su canción. Audio, letra, idioma, intérpretes y clasificación se editan independientemente.

Crear contenido editorial o del taller

Cada entidad contará con listado, alta, ficha, vista previa y ciclo de publicación apropiado. Blog y páginas tendrán editor y relaciones musicales. Capítulos y géneros se podrán crear desde cero. Los prompts tendrán listado propio y acceso contextual desde géneros y canciones. Los textos legales conservarán versiones y referencias históricas.

7. Borradores, publicación y medios

Guardar y publicar son operaciones distintas. Un contenido nuevo puede guardarse incompleto. «Listo para publicar» será un resultado calculado según las reglas de cada entidad.

Los cambios en un registro ya publicado se guardarán en una revisión de trabajo separada de la versión visible. Publicar aplicará la revisión validada de forma transaccional. La vista previa exigirá autorización, mostrará la revisión correcta y no será pública ni cacheable.

Los selectores de medios vivirán dentro de las fichas. La biblioteca global permitirá localizar archivos y ver sus usos. El procesamiento de audio mostrará subida, procesamiento, resultado o error recuperable; se conservarán las garantías contra sobrescrituras y pérdida de archivos registrados.

Las reglas de publicación se expresarán en lenguaje concreto y enlazarán con el apartado donde resolverlas. Faltas editoriales opcionales y bloqueos de publicación tendrán distinta importancia.

8. Pedidos y acceso

Pedidos, cuentas y suscripciones tendrán listados y fichas diferenciados. Desde una cuenta se verán sus compras y accesos; desde un pedido, sus artículos, importe, estado e incidencias.

La conciliación se ubicará en el pedido o en una bandeja de pagos pendientes. Introducir identificadores técnicos será una herramienta excepcional de recuperación, con ayuda y contexto. Los reembolsos seguirán tramitándose en Stripe. Los accesos de suscripción seguirán siendo manuales mientras no se defina otra modalidad comercial.

9. Arquitectura nueva y transición

• Aplicación administrativa nueva y aislada, con estructura y estilos propios. El panel existente permanece disponible durante su construcción.
• Servicios por dominio y contratos tipados definidos desde los casos de uso nuevos. Las rutas gestionan HTTP y autorización; los servicios aplican las reglas; las consultas preparan datos adecuados a cada pantalla.
• Componentes administrativos comunes para listados, filtros, fichas, relaciones, medios y publicación. La composición de pantallas seguirá las tareas de cada entidad.
• Esquema nuevo o adaptado mediante migraciones explícitas cuando lo requiera el modelo. Capa de compatibilidad temporal para que la web pública y las compras mantengan sus contratos.
• Revisiones persistidas, control de concurrencia y registro de actividad desde la base del sistema.
• Escritura con un único responsable por dominio durante el cambio. No se dejarán dos paneles modificando libremente modelos incompatibles ni se improvisará una doble escritura.
• Ensayo de migración sobre una copia aislada; verificación de recuentos, relaciones, archivos, URLs y derechos de compra. Copia de seguridad y procedimiento de recuperación ensayado antes del cambio real.
• Sustitución del panel antiguo cuando la nueva aplicación cubra los recorridos acordados; retirada posterior de código y estructuras obsoletas.

10. Fases y entregables

Fase	Entregable	Criterio de cierre
1. Definición	Mapa de tareas, entidades, relaciones, estados y reglas de publicación.	Los casos reales tienen una representación inequívoca, sin depender de las pantallas actuales.
2. Diseño	Sistema visual y prototipo navegable con catálogo, fichas y altas.	Se puede crear un artista, una canción, una versión y un lanzamiento, incluyendo dependencias que aún no existen.
3. Base técnica	Aplicación nueva, contratos, persistencia, revisiones, permisos, datos de prueba y estrategia de migración.	Primer recorrido completo sobre datos aislados y compatibilidad definida con la web pública.
4. Música	Altas, edición, relaciones, medios, versiones y publicación.	Un catálogo vacío puede convertirse en un lanzamiento publicado usando solo la interfaz.
5. Resto del producto	Contenido, taller, ventas, cuentas, suscripciones y mantenimiento.	Todas las entidades incluidas tienen recorridos completos y navegación consistente.
6. Migración y puesta en marcha	Ensayo de datos, pruebas, documentación y sustitución del panel.	Contenido, URLs, archivos y compras verificados; recuperación comprobada.

El primer resultado será el prototipo del producto nuevo. Las fases posteriores construirán sobre él. La aplicación actual no se irá retocando para parecerse a ese prototipo.

11. Criterios de aceptación

• Crear las entidades principales desde un catálogo vacío, sin scripts ni SQL.
• Crear relaciones inexistentes durante un alta sin perder el formulario original.
• Guardar incompleto, continuar después, previsualizar y publicar con reglas claras.
• Editar una versión sin modificar otras grabaciones de la misma canción.
• Incluir una grabación en dos lanzamientos sin duplicarla.
• Navegar entre artista, grabación, canción y lanzamiento sin perder el contexto.
• Encontrar contenido por relaciones, estado y pendientes; conservar filtros al volver.
• Resolver una carga fallida sin repetir la ficha ni eliminar medios registrados.
• Rechazar conflictos de edición sin sobrescribir cambios ajenos silenciosamente.
• Mantener el contenido público hasta publicar una nueva revisión.
• Conservar derechos de compra, entregas y referencias históricas tras la migración y la retirada de contenido.
• Completar los recorridos principales con teclado y en móvil.
• Probar la administración con cuentas y datos aislados, sin correos ni modificaciones sobre datos reales.

Alcance de este documento

Este documento conserva el diseño y los criterios de aceptación. La ejecución autorizada se recoge en Implementación de Estudio, con el estado real, las comprobaciones y los límites de la entrega.