MUSIC LIFE: de concepto a juego completo

00Cómo usar este documento

0.1 Qué es y qué no es

0.2 Documentos fuente

Esta guía se apoya en documentos que ya existen y no los repite; los cita por su nombre.

Regla de precedencia: lo que Enrique diga en el proyecto > esta guía aplicada > Visión v2 y sus anexos > decisiones v1 > guía maestra genérica.

0.3 Convenciones

• Códigos de agente. Cada participante tiene un código de tres letras (por ejemplo SIS para el diseñador de sistemas). El catálogo completo está en el apéndice A. ENR es Enrique.
• Pasos. Los pasos del plan se citan como #042. Están numerados de forma continua del primero al último en el apéndice C.
• Puertas. G0 a G5 como en la guía maestra; para la versión 1.0 se repiten como G3·1.0, G4·1.0 y G5·1.0.
• 👤 Acción humana. Marca lo que un agente no puede hacer solo: firmar, pagar, abrir cuentas a nombre de una persona o empresa, reclutar y moderar en persona a jugadores reales, aprobar una puerta.
• [D] Decisión tomada en esta guía. Las dudas que el encargo pedía resolver están decididas y anotadas en el apéndice D, con su motivo y cuándo se revisan.
• [E] Estimación. Cifra orientativa que se sustituye por un dato medido en cuanto exista.

0.4 Cómo se lee

1. Las secciones 1 y 2 dan la foto completa: decisiones clave, fases, fechas y criterios de cada puerta.
2. La sección 3 es la guía aplicada propiamente dicha: las 26 respuestas A1–A26.
3. La sección 4 baja a cada fase: qué entra, qué se entrega por disciplina y quién lo hace.
4. Los apéndices son la parte operativa: agentes (A), protocolo de trabajo (B), plan paso a paso (C), decisiones (D), matriz RACI (E) y estructura de carpetas (F).

Un equipo de agentes que quiera ejecutar el proyecto solo necesita el apéndice B para saber cómo trabajar y el apéndice C para saber qué hacer a continuación.

01Resumen ejecutivo

1.1 El juego en cinco líneas

MUSIC LIFE es un juego para PC de vida y carrera musical. Vives en primera persona la vida de un músico en Albor, una ciudad costera ficticia, con control directo del personaje (VIVE); compones música real con una herramienta accesible (CREA); la tocas en conciertos jugables (ACTÚA); gestionas dinero, banda y contratos desde el móvil del personaje (GESTIONA); y publicas tus canciones en un mundo compartido donde otros jugadores las escuchan, las compran y las suben a listas reales (CONECTA). Frase: "Vive la música. Crea la tuya. Haz que el mundo la escuche."

1.2 Las decisiones que condicionan todo el plan

1.3 Calendario objetivo [E]

Fechas para un arranque en diciembre de 2026. Se recalculan en G1 y G2 con la velocidad medida del equipo de agentes.

Se evitan octubre y noviembre para los lanzamientos por saturación del mercado, tal como recomienda el anexo de mercado.

02Ciclo de vida aplicado a MUSIC LIFE

2.1 Fases

La guía maestra define ocho fases. MUSIC LIFE las recorre todas, con dos particularidades: el vertical slice se alarga para incluir una demo pública, y la producción ocurre dos veces (primero hasta el acceso anticipado y después, con el juego ya a la venta, hasta la 1.0).

2.2 Hitos estándar traducidos

2.3 Puertas y criterios concretos

Cada puerta la convoca PROD, la preside ENR (👤) y se decide con un informe que reúne los entregables listados. Resultados posibles, como en la guía maestra: aprobar, aprobar con condiciones, repetir la fase o cancelar.

G0 · Concepto aprobado (diciembre 2026) - One-pager, pilares con ejemplos "sí/no" y fantasía del jugador aprobados. - Análisis de mercado 1.0 con la lectura de reseñas negativas de la competencia hecha. - Búsqueda de marca del título con resultado. - Registro de riesgos v0 con los cinco riesgos de diversión del anexo de mercado y los riesgos de online, alcance y título. - Presupuesto de F1 aprobado y política de IA del proyecto v1 firmada.

G1 · Fin de prototipos (mayo 2027) - Prototipo de papel: al menos 6 de cada 10 jugadores externos piden jugar "una semana más" tras 45 minutos. - Prototipo de Estudio: una persona sin formación musical compone una canción que le gusta en menos de 15 minutos (mínimo 8 de 12 participantes), y el Índice de Armonía medio de esas canciones es 60 o más. - Prototipo de Concierto: los participantes puntúan la diversión del directo con 4 o más sobre 5 de media. - Prototipo de Publicar y escuchar: 50 canciones publicadas por testers se descargan y suenan igual en tres equipos distintos; una lista semanal se calcula sin errores. - Prototipo VIVE: el control directo y el paso del tiempo no generan rechazo (al menos 7 de 10 prefieren caminar a saltar todo con la agenda). - Simulación sin gráficos de 1.000 carreras: ninguna estrategia degenerada (dinero infinito, quiebra en más del 80 % de partidas normales). - Motor confirmado, TDD 0.5 y riesgos técnicos principales con respuesta.

G2 · Greenlight a producción de EA (julio 2028) - Vertical slice jugado por al menos 20 externos con valoración media de 4 o más sobre 5. - Demo de Next Fest publicada; 5.000 listas de deseos o más al cierre del festival; retención D1 de la demo del 40 % o más; al menos el 60 % de quien juega la demo compone una canción. - GDD 1.0, TDD 1.0, biblias de arte, audio y narrativa 1.0. - Costes unitarios medidos (barrio, interior, personaje, storylet, instrumento, canción semilla, pantalla de UI) y plan de producción de EA calculado con ellos. - Presupuesto y financiación de F3 y F4 asegurados; estructura legal, términos de servicio y privacidad listos. - Si no se llega a 5.000 listas de deseos: no se cancela automáticamente, pero la puerta exige un plan de corrección (nuevo tráiler, cambio de gancho o de nombre) y una segunda medición en el siguiente Next Fest.

G3 · Alpha de EA (noviembre 2028): todas las funciones del alcance de EA dentro; cinco barrios recorribles; rendimiento a menos del 20 % del objetivo; guardado con migraciones funcionando; servicios online desplegados en el entorno de preproducción.

G4 · Beta de EA (enero 2029): contenido de EA completo, incluidas 2.000 canciones semilla en el catálogo; textos en español e inglés congelados; sin errores bloqueantes abiertos más de 7 días; prueba de carga a 3.000 jugadores simultáneos superada; beta cerrada online con 1.000 jugadores.

G5 · Lanzamiento de EA (abril 2029): cero errores de severidad A; moderación y soporte operativos con turnos definidos; plan de lanzamiento, guardia y comunicación listos; revisión de la tienda de Steam aprobada.

G3·1.0, G4·1.0 y G5·1.0: los mismos criterios aplicados al alcance de 1.0, más localización completa de los cinco idiomas, verificación de Steam Deck y valoración del EA del 85 % o más sostenida.

03Guía aplicada: las 26 respuestas

Cada apartado responde a la pregunta de la plantilla A1–A26 de la guía maestra, indica el entregable que la desarrolla, quién lo escribe y en qué paso del plan se cierra. El orden de cierre sigue la secuencia recomendada por la guía maestra: identidad y mercado, diseño núcleo, prototipos, tecnología, disciplinas creativas, equipo y dinero, resto, vertical slice y Definition of Ready.

A1. Identidad

Entregable: one-pager 1.0 (docs/vision/one-pager.md). Responsable: DIR, revisa MKT. Paso: #006.

A2. Pilares

Regla de uso: toda feature, asset o storylet nuevo indica en su ficha a qué pilar sirve. Lo que no sirve a ninguno va a la lista de cortes.

Entregable: sección de visión del GDD. Responsable: DIR, revisan NAR, SIS, MUS. Paso: #007.

A3. Público y mercado

• Personas de jugador (URS las redacta en #009):
• Laura, 27, juega a simuladores de vida. Quiere una vida con historia y personalización; nunca ha compuesto; abandona si la música suena mal o si hay demasiados menús.
• Dani, 34, juega a gestores deportivos y tycoons. Quiere sistemas profundos y "una semana más"; compone poco y usa Autocomponer; valora los números claros.
• Sara, 19, hace beats en el móvil. Quiere publicar y que la escuchen; le importan las listas y los featurings; poco interés en la gestión.
• Marcos, 22, streamer pequeño. Busca momentos compartibles: la separación de la banda, la canción del chat en la lista global.
• Competencia directa: Rock Star Life Simulator, Rising Star 2, Music Band Manager y Rockbeasts (enero de 2027). Detalle en el anexo de mercado.
• Diferenciación: ninguno combina composición real, directo jugable, mundo vivo emergente y canciones de jugadores compartidas con listas reales.
• Tamaño: el núcleo del género es de decenas de miles de compradores; el plan de negocio usa el escenario base de 50.000 unidades el primer año tras 1.0 y no depende del optimista.
• Tarea pendiente heredada: leer y clasificar las reseñas negativas de los competidores y revisar a mano los títulos sin verificar (Metalgods, Streaming Race, Music Wars Empire, Music Icon). Se hace en #008.

Entregable: análisis de mercado 1.0 (docs/business/market.md). Responsable: NEG con MKT y URS. Pasos: #008–#009.

A4. Plataformas y tecnología

Entregable: TDD 0.5 en G1 y 1.0 en G2 (tech/tdd.md). Responsable: TEC. Pasos: #066, #082.

A5. Loops y sistemas

Core loop (minutos): vivir el día en VIVE → elegir qué hacer (trabajar, componer, ensayar, socializar, tocar) → resolverlo jugando (Estudio, directo, conversación) o en la agenda → ver la consecuencia (dinero, fans, relación, titular).

Loop secundario (semanas): planificar la agenda 7×3 → equilibrar trabajo, música, vida y descanso → lanzar una canción o dar un concierto → leer resultados en el móvil y en las listas → ajustar.

Meta loop (años): subir peldaños de carrera (13 peldaños en 5 etapas) → cambiar o sumar roles → perseguir ambiciones → envejecer, retirarse y dejar legado o empezar otra vida en el mismo mundo.

Loop social (semanas reales): publicar en Waveline → escuchar y comprar canciones de otros → entrar en listas → colaborar, fichar o tocar en Noches abiertas → temporada con festival.

Lista de sistemas y su fase de entrada:

Entregable: GDD 0.5 en G1 y 1.0 en G2, con una spec por sistema según la plantilla de la sección 4.3 de la guía maestra. Responsables: SIS (sistemas de vida, carrera, economía, mundo), MUS (Estudio y directo), ONL (online), MUN (VIVE y ciudad), GUI (narrativa), coordinados por DIR. Pasos: #062 y #076–#083.

A6. Progresión y economía

• Moneda única del juego: euros de Albor (€). No hay moneda premium.
• Fuentes: trabajo (≈ 1.100 €/mes), actuaciones, streaming en Waveline (NPC y jugadores), ventas de canciones, sesiones como músico contratado, producción para otros, contratos y adelantos, negocio propio.
• Sumideros: alquiler (380 €/mes al inicio), comida y vida, instrumentos y equipo, local y estudio, promoción y videoclips, sueldos de banda y equipo, deudas.
• Curvas: la economía del primer año debe dejar al jugador "justo": el 60–70 % de las partidas simuladas llegan al mes 6 con menos de 1.000 € ahorrados y la decisión de dejar el trabajo se plantea entre el mes 5 y el 12.
• Progresión de carrera: escalera de 13 peldaños en 5 etapas; los umbrales dependen de las ambiciones elegidas.
• Atributos: 0–100, progresión lenta por práctica; sin techo por edad.
• Economía online: las compras de canciones de otros jugadores se pagan con dinero del juego; el autor recibe una parte en su partida. Un límite diario de ingresos procedentes de jugadores evita que el online rompa la economía de la partida en solitario.
• Validación: modelo en hoja de cálculo (F1) y simulación sin gráficos de miles de carreras con perfiles de bot (oportunista, constante, perfeccionista, caótico) antes de cada puerta.

Entregable: modelo de economía (design/economy/) con hoja, parámetros en JSON e informes de simulación. Responsable: SIS con DAT para el análisis y SIM para el simulador. Pasos: #023, #033, #037, #081.

A7. Narrativa

Entregables: biblia narrativa 0.5 (F1) y 1.0 (F2), outline del sistema narrativo, catálogo de storylets, fichas de personaje, guía de estilo de la Crónica. Responsables: NAR (dirección y biblia), GUI (escritura). Pasos: #063, #084–#088.

A8. Storyboards y previs

MUSIC LIFE no tiene cinemáticas lineales. Lo que necesita previsualización es:

A9. Dirección de arte

• Estilo: 3D estilizado, colorido, expresivo y legible; ni realista ni infantil. Personajes de proporciones algo estilizadas, caras simples con expresiones por textura, ropa modular. Ciudad mediterránea nocturna con neones y luces cálidas. La iluminación de escenario es protagonista.
• Identidad de interfaz: cartel de concierto y fanzine, con tramas y tintas planas. Paleta: rosa #FF4F8B, azul #2F5BEA, amarillo #FFD23F, tinta #1B1B22, papel #F3EBDD.
• Referencias: las imágenes conceptuales de docs/concept/v2/img/ son la base del mood board.
• Pipeline: concept → modelado en Blender → texturas con Substance 3D Painter → rig humanoide compatible con el sistema de animación de Unity → importación con validador automático. Kits modulares por barrio para reutilizar fachadas, interiores y mobiliario.
• Budgets por asset [E]: personaje base < 15.000 triángulos; prenda < 3.000; fachada modular < 2.000; interior completo < 150.000; texturas a 1024 px salvo héroes a 2048 px.
• Política de IA para arte (D-11): los agentes de arte pueden usar herramientas de generación con licencia que permita uso comercial y registro de procedencia; todo asset final pasa por revisión de ART y queda documentado; el uso se declara en Steam.

Entregable: biblia de arte 0.5 en F1 y 1.0 en F2 (art/bible/), con piezas de referencia "gold standard". Responsable: ART. Pasos: #064, #094–#103.

A10. Dirección de audio

Entregable: biblia de audio 0.5 (F1) y 1.0 (F2). Responsable: SON, con COM, SFX y AUD. Pasos: #065, #104–#109.

A11. UX y accesibilidad

• Pantallas principales: creación de personaje; VIVE (HUD mínimo: hora, energía, dinero, notificaciones); móvil con apps (Agenda, Banco, Mensajes, Redes, Waveline, Estudio, Trabajos, Contactos, Noticias/Crónica, Tienda, Contratos); Estudio; concierto (carril, energía de sala, decisiones); agenda semanal; radar de ambiciones; listas; perfil de artista; menús del sistema.
• Controles: teclado y ratón como principal; mando completo desde EA (necesario para Steam Deck y consolas); el Estudio usa ratón o teclado musical, con soporte de teclado MIDI desde EA.
• Accesibilidad desde el primer día: subtítulos y texto escalable; modos para daltonismo en el carril de ritmo; directo automático y dificultad ajustable; reasignación de controles; reducir movimiento y destellos en conciertos; tiempo pausable siempre; opción de lectura del móvil con tamaño grande; avisos visuales para eventos sonoros.
• Onboarding: la primera hora del anexo de sistemas, con objetivo de que al minuto 60 el jugador haya vivido una semana, un concierto y una decisión de dinero.

Entregable: guía de UX con mapa de pantallas, flujos, wireframes, sistema de diseño de interfaz y plan de accesibilidad. Responsable: UXD, con CON para el arte de interfaz y UIP para la implementación. Pasos: #059, #089–#093.

A12. Prototipos

Entregable: un informe por prototipo (docs/prototypes/P#.md) con datos y decisión. Pasos: #027–#061.

A13. Vertical slice

• Porción: las dos primeras horas de una partida nueva; Barrio Viejo y Campus a calidad final; interiores de piso, local de ensayo, bar El Faro, sala mediana, estudio y café del Campus.
• Contenido: creación de personaje con 3 orígenes, roles Solista y Músico de sesión/productor de beats, Estudio completo, tres tipos de actuación (calle, open mic, sala), radio con canciones de jugadores, 40 storylets, Crónica básica, 20 rivales detallados, listas básicas, móvil con 6 apps.
• Calidad: final en arte, audio, interfaz, narrativa y rendimiento dentro del budget.
• Medición: dos rondas de playtest con 20 externos en total; valoración ≥ 4/5; tiempo hasta la primera canción ≤ 15 min; 80 % completa el primer concierto; tasa de repetición de storylets < 10 % en 2 horas.
• Costes unitarios que debe dejar medidos: barrio, interior, personaje NPC, prenda, storylet, instrumento, canción semilla, pantalla de UI, minuto de música original.
• Demo: el VS pulido y recortado a 2–3 horas con Crónica final, más un servidor compartido abierto, para Steam Next Fest de junio de 2028.

Entregable: plan del VS (docs/production/vs-plan.md). Responsable: PROD con DIR. Paso: #075.

A14. Equipo

El equipo son 31 agentes de IA y un humano. El detalle de cada agente (rol, responsabilidades, entradas, salidas, a quién reporta) está en el apéndice A. Resumen por fase:

Personas y proveedores externos imprescindibles (👤, coordinados por PROD y contratados por ENR):

Entregable: plan de personal (docs/production/team.md). Responsable: PROD. Pasos: #003, #147.

A15. Producción

• Metodología: Scrum con sprints de dos semanas. En cada sprint, una build jugable revisada jugando por DIR, PROD, QAT y los líderes. Kanban para comunidad, soporte y live ops a partir del EA.
• Organización: tres equipos funcionales de agentes ("pods") durante la producción: Vida (VIVE, sistemas de vida, mundo, narrativa), Música (Estudio, directo, motor musical, catálogo) y Conecta (online, listas, moderación, temporadas). Cada pod tiene su diseñador líder, sus ingenieros, apoyo de arte y audio, y un QA asignado.
• Herramientas: GitHub (repositorio, incidencias, tablero de proyectos e integración continua); documentación en Markdown dentro del repositorio; hojas de cálculo para economía; Figma para interfaz; Blender y Substance 3D para arte; FMOD Studio para audio; Discord para comunidad; Steamworks.
• Ritmo de agentes: cada agente trabaja por pasos del apéndice C. PROD asigna, vigila dependencias y desbloquea. Las reglas están en el apéndice B.
• Hitos y calendario: sección 1.3.

Entregable: plan maestro (docs/production/master-plan.md) y tablero. Responsable: PROD. Pasos: #001, #072, #143.

A16. Presupuesto y financiación

Con un equipo de agentes, el coste deja de ser mayoritariamente salarial. Las partidas son cómputo de los agentes, licencias, servicios externos humanos, infraestructura y marketing.

Escenario de respaldo: si en G1 la velocidad o la calidad de los agentes en arte 3D, audio o pulido no alcanza el estándar, se contrata a personas para esas disciplinas. El anexo online estima 1,1–1,9 M€ con equipo humano remunerado completo; un equipo mixto se sitúa entre ambos.

Financiación: fondos propios de ENR hasta G1; en F2, ayudas públicas a videojuegos (convocatorias estatales del Ministerio de Cultura, Europa Creativa MEDIA, ayudas autonómicas) y, opcionalmente, editor o inversor con la demo en la mano; desde el EA, ingresos de ventas reinvertidos. NEG verifica las convocatorias vigentes y sus plazos en #069.

Entregable: presupuesto detallado y business case. Responsable: NEG. Pasos: #012, #070, #134.

A17. Modelo de negocio

Nunca se monetiza: posición en listas, escuchas, visibilidad, atributos, dinero del juego, velocidad de progreso, calidad de producción, cajas de botín ni dinero real entre jugadores.

KPIs objetivo: retención D1 ≥ 40 %, D7 ≥ 20 %, D30 ≥ 9 %; sesión media de 60–90 min; ≥ 60 % compone una canción y ≥ 30 % publica una; valoración en Steam ≥ 85 %; reembolsos < 8 %. Escenario base: 50.000 unidades el primer año tras 1.0 y ≈ 570 k€ netos.

Entregable: business case 1.0. Responsable: NEG con MKT. Paso: #134.

A18. Legal

Entregable: checklist legal (docs/legal/checklist.md). Responsable: LEG, con revisión de un abogado humano en cada puerta.

A19. Calidad

• Plan de QA: pruebas unitarias y de integración del núcleo en cada cambio; validación automática de datos de contenido; bots que juegan carreras completas sin gráficos cada noche; pruebas de regresión de la build; pruebas de compatibilidad en tres perfiles de hardware; pruebas de carga del online antes de cada lanzamiento; pruebas de moderación con contenido de prueba; pruebas de accesibilidad; LQA de idiomas.
• Gestión de errores: severidades A (bloqueante) a D (cosmético); triaje dos veces por semana; ningún error A abierto más de 48 h desde Alpha.
• Plan de investigación de usuarios: playtests en cada fase (papel, prototipos, VS en dos rondas, demo pública, beta cerrada online, EA con telemetría); encuestas y entrevistas; personas reales reclutadas por ENR y la comunidad, con sesiones remotas grabadas con consentimiento que URS analiza.

Entregables: plan de QA y plan de UR. Responsables: QAT y URS. Pasos: #067, #068, #120, #122–#124.

A20. Datos

• Preguntas que debe responder la telemetría: ¿dónde abandonan en la primera hora? ¿Cuántos componen y publican? ¿Qué modo juegan más? ¿Qué storylets se repiten? ¿Qué estrategias económicas dominan? ¿Cuánto se escucha música de otros jugadores? ¿Hay granjas de escuchas?
• Eventos núcleo: inicio y fin de sesión, creación de personaje, cada actividad de agenda, canción creada y publicada, concierto iniciado y terminado con resultado, storylet mostrado y elegido, compra, escucha de canción ajena, reporte, ajustes de accesibilidad.
• Privacidad: anónima por defecto, con consentimiento según RGPD; sin datos personales en los eventos.
• Herramientas: eventos propios enviados al backend y almacenados en un almacén de datos; paneles de control para PROD, DIR y ONL.

Entregable: documento de telemetría y paneles. Responsable: DAT. Pasos: #117, #172.

A21. Localización

• Idiomas: español (original) e inglés desde la demo; portugués de Brasil, francés y alemán en 1.0; chino simplificado tras 1.0 si hay tracción.
• Nivel: interfaz y texto completo; sin doblaje.
• Retos propios: el texto procedural (storylets, Crónica, biografía) necesita plantillas con género y número gramatical y variables con metadatos; las letras de canciones de jugadores no se traducen; nombres ficticios del mundo se mantienen.
• Proceso: textos externalizados desde F1; pseudolocalización en F2; traducción por LOC con glosario y memoria de traducción; revisión humana nativa y LQA antes de cada lanzamiento.

Entregable: plan de localización. Responsable: LOC. Pasos: #026, #118, #173, #215.

A22. Marketing y comunidad

• Posicionamiento: "el simulador de vida musical donde tu canción suena en el mundo de otros". Ganchos para clips: tu canción en la radio de otro jugador, la banda que se separa, la Crónica con tu titular.
• Calendario: anuncio y página de Steam en octubre de 2027 con primer tráiler; Discord abierto desde el anuncio; demo en Next Fest de junio de 2028; tráiler de EA y campaña con creadores en marzo de 2029; tráiler de 1.0 en mayo de 2030.
• Canales: Steam, Discord, TikTok, YouTube, Instagram y X; creadores de contenido de simuladores y de música; prensa especializada.
• Objetivos de listas de deseos: 2.000–3.000 antes de Next Fest; 5.000 o más tras el festival; 10.000 o más al lanzar el EA.
• Comunidad: Discord con canales por barrio y género; concursos de canciones; programa de testers; moderadores voluntarios.

Entregable: plan de marketing. Responsable: MKT. Pasos: #128–#130, #139, #180, #188.

A23. Lanzamiento

• Estrategia: acceso anticipado en Steam en abril de 2029 tras la demo, con hoja de ruta pública prudente (solo lo que entra en los seis meses siguientes); 1.0 en junio de 2030 con subida de precio anunciada.
• Plataformas: PC; Steam Deck en 1.0; consolas después.
• Operación: sala de guerra durante 14 días en cada lanzamiento, con turnos de BAK, OPS, QAT, TYS y PROD; parche de día uno preparado; ajustes de equilibrio en caliente desde el servidor.

Entregable: plan de lanzamiento. Responsable: PROD con MKT y OPS. Pasos: #191, #194, #229.

A24. Live ops

• Durante el EA: actualización mayor cada 6–8 semanas y temporadas de 10–12 semanas con festival final.
• Tras 1.0: temporadas continuas; una expansión de pago al año (nueva ciudad o época); Steam Workshop para storylets, géneros, nombres e instrumentos; consolas con la primera expansión.
• Herramientas: calendario de temporadas, panel de eventos, ajuste remoto de parámetros, panel de moderación, soporte con base de conocimiento.

Entregable: roadmap de live ops. Responsable: ONL con PROD. Pasos: #232–#241.

A25. Riesgos

Entregable: registro de riesgos vivo. Responsable: PROD, revisado en cada sprint. Pasos: #011 y revisión continua.

A26. Definition of Ready

Estado al escribir esta guía y paso que cierra cada casilla de la sección 26 de la guía maestra:

El checklist firmado se emite en G2 (#144–#146).

04Qué hay que hacer y quién, fase a fase

Esta sección resume el trabajo de cada fase por disciplina. El detalle ejecutable, paso a paso, está en el apéndice C.

4.1 F0 · Cierre del concepto (diciembre 2026)

Objetivo: convertir la Visión v2 y sus anexos en un concepto aprobado, con el título verificado, los riesgos explícitos y el dinero de la preproducción decidido. Pasos #001–#020.

Punto de partida: el concepto está muy avanzado (visión, pitch con imágenes, GDD de sistemas, anexo online y de negocio, análisis de mercado y de motores). Lo que falta es cerrarlo con los entregables formales de la puerta G0.

No entra en F0: nada de motor ni de arte final.

4.2 F1 · Preproducción: prototipos (enero a mayo de 2027)

Objetivo: responder con evidencia a las preguntas P1–P8 de A12 y dejar escritas las versiones 0.5 de GDD, TDD y biblias. Pasos #021–#074.

No entra en F1: arte final, más de una calle, online real con usuarios, localización real (sí la externalización de textos).

4.3 F2 · Vertical slice y demo (junio de 2027 a julio de 2028)

Objetivo: demostrar la calidad final en una porción y medir el interés del público con una demo. Cerrar la Definition of Ready. Pasos #075–#146.

No entra en F2: los tres barrios restantes, bandas autónomas, Noches abiertas, temporadas.

4.4 F3 · Producción hacia el acceso anticipado (agosto de 2028 a enero de 2029)

Objetivo: construir el alcance completo del EA en sprints, con tres pods. Pasos #147–#182.

Alcance del EA: cinco barrios con metro y bici; roles Solista, Miembro de banda, Productor y Músico de sesión; bandas con miembros autónomos y conflictos; relaciones con memoria; 100 agentes del mundo vivo; tendencias completas; 150 storylets; ambiciones e indicadores; móvil con 11 apps; Estudio con instrumentos ampliados y teclado MIDI; directo en calle, open mic, sala y festival; Waveline con listas semanales completas, playlists y featurings; Noches abiertas (jams de 4 y open mics por barrio); primera temporada; moderación completa y control parental; español e inglés; mando completo.

Hitos: Alpha de EA (G3) en noviembre de 2028; Beta de EA (G4) en enero de 2029.

4.5 F4 · Postproducción y lanzamiento del EA (febrero a abril de 2029)

Objetivo: pulir, estabilizar, probar el online bajo carga, preparar la operación y lanzar. Pasos #183–#196.

4.6 F5 · Producción de 1.0 durante el EA (mayo de 2029 a abril de 2030)

Objetivo: completar el juego con jugadores reales dentro, en ciclos de actualización de 6–8 semanas. Pasos #197–#220.

Alcance de 1.0 añadido al EA: los 8 roles (con DJ, Compositor para otros, Mánager y Empresario); camino empresarial (estudio, sello, sala, promotora, festival); sellos de jugadores y contratos entre jugadores; mundo vivo a 300 agentes con LOD; fusiones de géneros con nombre y revivals; carreras de 20–50 años, envejecimiento, jubilación, biografía y documental; legado entre vidas; 300 storylets; conciertos de jugadores con público en Noches abiertas; festivales de temporada y premios de comunidad; DJ set; 40–60 instrumentos; localización a portugués de Brasil, francés y alemán; modding con JSON y Steam Workshop; Steam Deck; tienda de cosméticos y paquetes de sonido; banda sonora.

4.7 F6 · Postproducción y lanzamiento de 1.0 (abril a junio de 2030)

Objetivo: cerrar 1.0 con calidad de lanzamiento completo. Pulido, LQA de cinco idiomas, verificación de Steam Deck, prueba de carga a 100.000 jugadores activos al mes, tienda de cosméticos, tráiler, campaña, cambio de precio, sala de guerra. Pasos #221–#231.

4.8 F7 · Live ops, consolas y expansiones (desde julio de 2030)

Objetivo: mantener el juego vivo, crecer y llevarlo a otras plataformas. Temporadas cada 10–12 semanas; Workshop y comunidad; expansión anual; port a consolas con certificación y clasificación por edades; revisión anual del negocio. Pasos #232–#241.

4.9 F8 · Fin de vida

Objetivo: cuando los indicadores lo aconsejen (ingresos por debajo del coste de operación durante 6 meses o decisión de ENR), cerrar los servicios online dejando el juego jugable sin conexión, permitir a los jugadores exportar sus canciones y su biografía, comunicarlo con 6 meses de antelación y escribir el post-mortem final. Pasos #242–#246.

4.10 Rutinas que se repiten en todas las fases

Estas tareas no aparecen como pasos numerados porque se repiten. PROD las agenda desde #001 hasta el final del proyecto.

AParticipantes: el equipo de agentes

A.0 Organigrama

Son 31 agentes. Cada uno es una instancia de IA con un mandato, unas herramientas y unos límites. Ninguno aprueba una puerta, firma, paga ni publica fuera del proyecto sin la aprobación de ENR.

A.1 Responsable humano

ENR · Enrique, productor ejecutivo

• Rol: dueño del proyecto y de la visión; único aprobador de puertas y de acciones irreversibles.
• Responsabilidades: aprobar G0–G5; aprobar presupuesto y gastos; firmar contratos y cesiones; abrir cuentas (Steamworks, banco, dominios, redes, plataformas de consola); dar de alta la forma jurídica; reclutar y atender a jugadores de playtest cuando haga falta una persona; resolver conflictos que la dirección no cierre.
• Recibe: informe semanal de PROD; paquetes de puerta; solicitudes de aprobación marcadas 👤.
• Entrega: decisiones registradas en docs/decisions/; firmas; credenciales a los agentes que las necesiten mediante un gestor de secretos (nunca en documentos).
• Tiempo estimado: 3–6 horas por semana; más en puertas y lanzamientos.

A.2 Dirección

DIR · Dirección de juego y creativa

• Rol: guardián de la visión, los pilares y la experiencia completa; árbitro final de diseño.
• Responsabilidades: one-pager y pilares; dirección del GDD; aprobar specs de diseño; revisar cada build jugando; decidir cortes de contenido junto con PROD; garantizar coherencia entre juego, narrativa, arte y audio.
• Entradas: Visión v2, anexos, informes de playtest (URS), datos (DAT), propuestas de diseñadores.
• Salidas: one-pager, visión del GDD, aprobaciones de specs, notas de revisión, lista de cortes.
• Reporta a: ENR. Supervisa: ART, SON, NAR, SIS, MUS, ONL, UXD, MUN, URS.
• Límites: no cambia los pilares ni el alcance de una fase sin pasar por ENR.

PROD · Producción y orquestación

• Rol: productor y director de desarrollo; orquestador del equipo de agentes.
• Responsabilidades: mantener el plan maestro, el tablero y el registro de decisiones; asignar pasos del apéndice C según dependencias; vigilar bloqueos; preparar paquetes de puerta; medir velocidad y costes unitarios; gestionar el registro de riesgos; coordinar externos; escribir el informe semanal; dirigir las rutinas de la sección 4.10; mantener esta guía viva.
• Entradas: este documento, estado del tablero, informes de cada agente, incidencias de QAT.
• Salidas: plan maestro, tablero, actas, paquetes de puerta, informe semanal, registro de riesgos, presupuesto ejecutado (con NEG).
• Reporta a: ENR. Supervisa: QAT, DAT, MKT, LOC, TYS; coordina a todos.
• Límites: no decide diseño (lo hace DIR) ni tecnología (TEC); propone cortes, no los impone.

TEC · Dirección técnica

• Rol: responsable de la arquitectura, el motor, la calidad del código y los riesgos técnicos.
• Responsabilidades: TDD; decisión de motor y middleware; formato .mlsong; budgets de rendimiento y memoria; revisión de código de los agentes de ingeniería; prototipos técnicos; arquitectura online con BAK; seguridad.
• Entradas: GDD y specs, requisitos de arte y audio, informes de rendimiento.
• Salidas: TDD 0.5 y 1.0, decisiones técnicas, estándares de código, revisiones.
• Reporta a: ENR. Supervisa: SIM, AUD, JUE, UIP, BAK, OPS.
• Límites: no adopta un servicio de pago ni una licencia nueva sin LEG y ENR.

NEG · Negocio y finanzas

• Rol: business case, presupuesto, financiación y precios.
• Responsabilidades: análisis de mercado; presupuesto por fase y seguimiento del gasto; ayudas públicas y búsqueda de financiación; precios regionales; proyecciones y KPIs de negocio; preparación de documentación para editores o inversores.
• Entradas: anexos de mercado y negocio, datos de ventas y listas de deseos, costes de PROD.
• Salidas: análisis de mercado, presupuesto, business case, solicitudes de ayudas (borradores), informes de negocio.
• Reporta a: ENR.
• Límites: no presenta solicitudes ni firma acuerdos: lo hace ENR.

LEG · Legal y cumplimiento

• Rol: asesor legal interno; prepara y vigila, y deriva al abogado humano lo que exige firma o criterio profesional.
• Responsabilidades: forma jurídica; política de IA; marca; licencias; inventario de propiedad intelectual y procedencia; términos de servicio, privacidad y política de contenido; RGPD, LOPDGDD y Ley de Servicios Digitales; menores; clasificación por edades; contratos tipo.
• Entradas: decisiones de producto, lista de herramientas y proveedores, flujos de datos.
• Salidas: checklist legal, políticas, borradores de contratos, informes de marca y licencias.
• Reporta a: ENR. Colabora con: abogado externo 👤, TYS, TEC.
• Límites: sus documentos no son asesoramiento jurídico definitivo; todo lo que se firma lo revisa un abogado humano.

A.3 Dirección creativa

ART · Dirección de arte

• Rol: visión visual y calidad del arte.
• Responsabilidades: biblia de arte; mood boards; aprobar todo asset final; budgets de arte con TEC; pipeline de arte con OPS; aplicar la política de IA en arte y registrar la procedencia.
• Entradas: Visión v2 (sección de arte), imágenes de concepto v2, GDD.
• Salidas: biblia de arte 0.5 y 1.0, assets gold standard, revisiones.
• Reporta a: DIR. Supervisa: CON, PER, ENT.

SON · Dirección de audio y música

• Rol: visión sonora del juego y calidad musical.
• Responsabilidades: biblia de audio; criterios de "suena bien" con MUS; aprobar instrumentos, kits, canciones semilla y efectos; mezcla final; elección de muestras con licencia; banda sonora original.
• Entradas: GDD, specs del Estudio y del directo, requisitos técnicos de AUD.
• Salidas: biblia de audio, aprobaciones, mezcla de referencia.
• Reporta a: DIR. Supervisa: COM, SFX.

NAR · Dirección narrativa

• Rol: dueño del mundo de Albor, de su gente y del sistema de historias.
• Responsabilidades: biblia narrativa; reglas del Narrador; diseño del sistema de storylets con SIS; fichas de personaje; guía de estilo de la Crónica; coherencia de lore; revisión de todo texto.
• Entradas: Visión v2, anexo de sistemas (motor narrativo), GDD.
• Salidas: biblia narrativa, outline del sistema, fichas, guía de estilo.
• Reporta a: DIR. Supervisa: GUI.

A.4 Diseño

SIS · Diseño de sistemas, economía y equilibrio

• Responsabilidades: specs de tiempo y agenda, personaje, roles, relaciones, bandas, mundo vivo, tendencias, economía, ambiciones, progresión y legado; modelo de economía; prototipo de papel; ajuste de parámetros con simulación masiva.
• Entradas: anexo de sistemas, informes de SIM y DAT, playtests.
• Salidas: specs, hojas de economía, parámetros en JSON, informes de equilibrio.
• Reporta a: DIR. Colabora con: SIM, DAT, NAR.

MUS · Diseño de música y directo

• Responsabilidades: specs de CREA (Estudio, asistentes, Autocomponer, Índice de Armonía, calidad por personaje y equipo) y de ACTÚA (carril de ritmo, dificultad, gestión de sala, tipos de actuación); criterios de calidad musical; playtests musicales.
• Entradas: anexo online (secciones 1 y 2), biblia de audio.
• Salidas: specs, tablas de parámetros, informes de pruebas.
• Reporta a: DIR. Colabora con: AUD, COM, JUE, SON.

ONL · Diseño online, comunidad y live ops

• Responsabilidades: specs de CONECTA (Waveline, listas, anti-trampas, ventas, playlists, featurings, sellos, Noches abiertas, temporadas, festivales, premios); reglas de convivencia con TYS; calendario de temporadas; roadmap de live ops.
• Entradas: anexo online (secciones 3 y 4), datos de DAT.
• Salidas: specs online, calendario de temporadas, roadmap de live ops.
• Reporta a: DIR. Colabora con: BAK, TYS, DAT.

UXD · UX, UI y accesibilidad

• Responsabilidades: mapa de pantallas, flujos y wireframes; sistema de diseño de interfaz con la identidad de cartel; FTUE; plan de accesibilidad; pruebas de usabilidad con URS.
• Entradas: GDD, biblia de arte, informes de playtest.
• Salidas: guía de UX, archivos de Figma, specs de pantallas.
• Reporta a: DIR. Colabora con: CON, UIP.

MUN · Diseño de mundo, ciudad y niveles

• Responsabilidades: mapa de Albor; layout de cada barrio y de los interiores; puntos de interés; metro y bici; rutinas de NPC en el espacio; colocación de actividades; greybox.
• Entradas: biblia narrativa, biblia de arte, GDD.
• Salidas: mapas, greyboxes, listas de interiores y props por barrio.
• Reporta a: DIR. Colabora con: ENT, JUE, NAR.

A.5 Narrativa

GUI · Guion de storylets, diálogos y Crónica

• Responsabilidades: escribir storylets con sus precondiciones, variantes y consecuencias; diálogos de NPC en Yarn Spinner; plantillas de titulares, entrevistas y biografía con variables gramaticales; textos de interfaz con UXD.
• Entradas: biblia narrativa, guía de estilo, specs de SIS.
• Salidas: archivos de contenido validados por el esquema.
• Reporta a: NAR.

A.6 Ingeniería

SIM · Núcleo de simulación

• Responsabilidades: núcleo en C# puro, determinista y sin dependencias del motor: tiempo, agenda, personaje, economía, roles, relaciones, bandas, mundo vivo con LOD, tendencias, storylets y Narrador, Crónica, guardado y semillas; simulador masivo de carreras con bots.
• Entradas: specs de SIS, NAR y ONL; TDD.
• Salidas: núcleo con pruebas automáticas; informes de simulación.
• Reporta a: TEC.

AUD · Motor musical y programación de audio

• Responsabilidades: secuenciador, sampler, sintes y efectos; formato .mlsong con TEC; Autocomponer; Índice de Armonía; generación del carril de ritmo; integración con FMOD; rendimiento de audio.
• Entradas: specs de MUS, biblia de audio, muestras de COM.
• Salidas: motor musical con pruebas de determinismo y rendimiento.
• Reporta a: TEC.

JUE · Gameplay y cliente

• Responsabilidades: VIVE (control, cámara, interacción, transición a agenda), ACTÚA (carril, público, cámaras, luces), integración de arte y animación, NPC en escena, rendimiento del cliente.
• Entradas: specs, greyboxes de MUN, assets de arte.
• Salidas: escenas y sistemas jugables en el cliente.
• Reporta a: TEC.

UIP · Programación de interfaz

• Responsabilidades: móvil y sus apps, Estudio, HUD, menús, opciones de accesibilidad, mando, i18n en interfaz.
• Entradas: guía de UX y Figma de UXD, arte de interfaz de CON.
• Salidas: interfaz implementada.
• Reporta a: TEC.

BAK · Backend y online

• Responsabilidades: cuentas con Steam; catálogo de canciones; escuchas, ventas y listas; anti-trampas; playlists, featurings, sellos; salas en vivo; moderación automática y cola de reportes; temporadas; telemetría en servidor; pruebas de carga; guardia en lanzamientos.
• Entradas: specs de ONL, TDD, políticas de LEG y TYS.
• Salidas: servicios desplegados, paneles de operación, manuales de incidencias.
• Reporta a: TEC.

OPS · Build, herramientas y publicación

• Responsabilidades: repositorio y control de versiones; integración continua; builds nocturnas; validadores de datos y de assets; herramientas internas (editor de storylets, visor de canciones); Steamworks (ramas, depósitos, builds); proceso de Release Candidate y Gold; modding y Workshop.
• Entradas: TDD, necesidades de los demás agentes.
• Salidas: pipelines y builds.
• Reporta a: TEC.

A.7 Arte

CON · Concept, ilustración e interfaz

• Responsabilidades: concept de barrios, interiores, personajes y props; storyboards; key art; arte de interfaz (iconos, tramas, carteles); capsulas de Steam y piezas de marketing con MKT.
• Salidas: concepts aprobados por ART, arte de interfaz, key art.
• Reporta a: ART.

PER · Personajes 3D y animación

• Responsabilidades: sistema de personaje modular (cuerpos, caras, peinados, ropa); rigging; animaciones de vida y de tocar cada instrumento; reacciones de público; NPC con nombre.
• Salidas: personajes y animaciones importados y validados.
• Reporta a: ART. Colabora con: JUE.

ENT · Entornos, iluminación y efectos

• Responsabilidades: kits modulares por barrio; interiores; props; iluminación de día, noche y escenario; efectos visuales de conciertos y ciudad.
• Salidas: escenas de barrio e interiores a calidad final.
• Reporta a: ART. Colabora con: MUN, JUE.

A.8 Audio

COM · Composición, instrumentos y catálogo

• Responsabilidades: preparar instrumentos y kits a partir de muestras con licencia o síntesis; presets por género; plantillas de Autocomponer con AUD; canciones semilla del catálogo (300 en el VS, 2.000 en EA); música original y banda sonora.
• Salidas: bibliotecas de instrumentos, canciones .mlsong, música original.
• Reporta a: SON.

SFX · Diseño de sonido

• Responsabilidades: efectos, ambientes por barrio y hora, público por tamaño de sala, interfaz del móvil, vocalizaciones no verbales; implementación en FMOD.
• Salidas: bancos de FMOD integrados.
• Reporta a: SON.

A.9 Calidad

QAT · QA y automatización

• Responsabilidades: plan de QA; pruebas automáticas y bots; regresión de builds; compatibilidad; pruebas de carga con BAK; triaje; criterios de entrada y salida de hitos; verificación de accesibilidad.
• Salidas: informes de calidad, incidencias, aprobación técnica de builds candidatas.
• Reporta a: PROD (independiente de quien construye).

URS · Investigación de usuarios y playtests

• Responsabilidades: plan de UR; guiones de sesión; encuestas; análisis de grabaciones y respuestas; informes con recomendación. Las sesiones necesitan personas reales: ENR y la comunidad reclutan 👤 y URS prepara y analiza.
• Salidas: informes de playtest con datos y decisión propuesta.
• Reporta a: DIR.

A.10 Operación y mercado

DAT · Datos y telemetría

• Responsabilidades: plan de telemetría; eventos; paneles; análisis de simulaciones masivas con SIS; detección de anomalías y de fraude en listas con BAK; informes de KPIs.
• Reporta a: PROD.

MKT · Marketing, comunidad y creadores

• Responsabilidades: posicionamiento; página de Steam; tráileres; redes; Discord; kit de prensa; relación con creadores y prensa; campañas de Next Fest, EA y 1.0; listas de deseos. Toda publicación externa la aprueba ENR 👤 hasta que conceda permiso permanente para un canal.
• Reporta a: PROD.

LOC · Localización

• Responsabilidades: i18n con UIP; glosario; memoria de traducción; traducción; pseudolocalización; coordinación de revisores nativos humanos 👤; LQA.
• Reporta a: PROD.

TYS · Moderación, soporte y seguridad (Trust & Safety)

• Responsabilidades: política de contenido; filtros y listas; panel y cola de reportes; decisiones de moderación motivadas; control parental; soporte al jugador; base de conocimiento; coordinación de moderadores voluntarios. Las sanciones graves (bloqueo de cuenta) las confirma una persona 👤.
• Reporta a: PROD. Colabora con: ONL, BAK, LEG.

BProtocolo de trabajo de los agentes

Este apéndice dice cómo se ejecuta el plan del apéndice C. Lo aplica PROD y lo cumplen todos.

B.1 Fuente única de verdad

• Todo vive en el repositorio del proyecto (estructura en el apéndice F). Un documento que no está en el repositorio no existe.
• Las decisiones se escriben en docs/decisions/ con número, fecha, quién decide, motivo y qué documentos cambia. Si un documento contradice una decisión registrada, manda la decisión y el documento se corrige.
• Las biblias (arte, audio, narrativa), el GDD y el TDD son contratos: un agente que necesite apartarse de ellos lo propone a su director, no lo hace por su cuenta.

B.2 Ficha de paso

Cada paso del apéndice C se convierte en una tarjeta del tablero con estos campos:

B.3 Estados del tablero

Pendiente → Listo (todas sus dependencias hechas) → En curso → En revisión → Hecho · con Bloqueado posible en cualquier punto, siempre con el motivo y a quién se espera.

B.4 Reglas

1. Un paso empieza solo cuando sus dependencias están en Hecho. PROD puede autorizar un arranque anticipado si el riesgo es bajo y lo anota.
2. Todo entregable pasa por un revisor distinto de su autor. El revisor comprueba el criterio de hecho, la coherencia con las biblias y los pilares, y que no contradice el registro de decisiones.
3. Dos rondas de revisión como máximo. Si a la tercera sigue sin aprobarse, decide el director del área; si el conflicto es entre áreas, decide DIR (diseño), TEC (técnica) o PROD (plazos y alcance), y si no, ENR.
4. Las acciones 👤 no las hace un agente. El agente prepara todo lo necesario y crea una solicitud para ENR con lo que hay que hacer, el motivo, el coste y el plazo.
5. Nada sale del proyecto sin ENR. Publicar en Steam o redes, enviar correos a terceros, gastar dinero, aceptar licencias o firmar requiere su aprobación, salvo permiso permanente que él conceda por escrito para un canal concreto.
6. Procedencia. Todo asset y texto registra qué agente lo hizo, con qué herramientas y modelos, y qué fuentes externas usó. Ningún asset final contiene material de terceros sin licencia registrada por LEG.
7. Originalidad. Ningún agente reproduce personajes, marcas, logotipos, canciones, letras ni diseños reconocibles de juegos u obras existentes. Las referencias se usan como inspiración documentada, no como fuente para copiar.
8. Pequeño y verificable. Un paso que un agente no puede entregar en un sprint se divide en subpasos (#042.1, #042.2) antes de empezar.
9. Build jugable siempre. Desde F1 la rama principal compila y se puede jugar; quien la rompe la arregla antes de seguir.
10. Medir. Cada paso registra su tiempo y su coste de cómputo; PROD los convierte en costes unitarios para planificar.

B.5 Escalado

B.6 Paquete de puerta

PROD prepara cada puerta con: resumen de una página; criterios de la sección 2.3 con evidencia enlazada (cumple, no cumple, parcial); entregables de la fase; presupuesto ejecutado y siguiente; riesgos; recomendación (aprobar, aprobar con condiciones, repetir, cancelar). ENR decide y su decisión se registra.

CPlan paso a paso, del primero al último

246 pasos en nueve fases. Se ejecutan en orden de dependencias, no necesariamente en orden numérico: dentro de una fase, los pasos sin dependencias entre sí avanzan en paralelo. La columna Necesita lista los pasos previos imprescindibles. 👤 marca intervención humana. Las rutinas recurrentes (sección 4.10) se ejecutan en paralelo a todo el plan.

C.0 · F0 Cierre del concepto (#001–#020)

C.1 · F1 Preproducción: prototipos (#021–#074)

Fundaciones

Prototipo de papel (P1)

Núcleo y simulación (P6)

Música (P2 y P7)

Directo (P3)

Online (P4)

VIVE, personaje e interfaz (P5 y P8)

Documentos 0.5, negocio y puerta

C.2 · F2 Vertical slice y demo (#075–#146)

Planificación y documentos 1.0

Narrativa

Experiencia de usuario

Arte

Audio

Ingeniería

Integración y validación

Mercado, negocio y legal

Demo y Next Fest

Greenlight

C.3 · F3 Producción hacia el acceso anticipado (#147–#182)

Arranque y specs del EA

Pod Vida

Pod Música

Pod Conecta

Transversal, Alpha y Beta

C.4 · F4 Postproducción y lanzamiento del EA (#183–#196)

C.5 · F5 Producción de 1.0 durante el EA (#197–#220)

C.6 · F6 Postproducción y lanzamiento de 1.0 (#221–#231)

C.7 · F7 Live ops, consolas y expansiones (#232–#241)

C.8 · F8 Fin de vida (#242–#246)

DRegistro de decisiones: dudas resueltas en esta guía

El encargo pedía decidir las dudas y anotarlas. Estas son las decisiones tomadas, con su motivo y cuándo se revisan. Enrique puede cambiar cualquiera; el cambio se registra en docs/decisions/ y se propaga a esta guía.

EMatriz RACI aplicada

R = realiza · A = aprueba · C = consultado · I = informado.

FRepositorio y nomenclatura

El repositorio del proyecto ya existe: github.com/ealvarpe/music-life (privado). La estructura objetivo es esta; PROD la completa en #001 y OPS añade la parte de código en #021.

Nomenclatura: nombres de archivos, carpetas y rutas siempre en inglés (el juego será multiidioma), aunque el contenido de los documentos esté en español; archivos en minúsculas con guiones; versiones en el nombre solo para entregables de puerta (gdd-1.0.md); identificadores de contenido con prefijo de tipo (stl_ storylet, npc_, ins_ instrumento, loc_ localización, bar_ barrio, int_ interior).

Guía maestra aplicada a MUSIC LIFE, versión 1.0, noviembre de 2026. Documento vivo: PROD la actualiza tras cada puerta y cada post-mortem. Las condiciones comerciales de motores, plataformas, servicios y ayudas públicas, y la normativa citada, cambian con frecuencia y deben verificarse en la fuente oficial antes de decidir.