# SPRINT v0.1.26 — NEXT (GLM)
## Coherence First, Less Choppy, Less Template Song

**Owner:** GLM via OpenCode  
**Reviewer:** Codex  
**Fecha:** 2026-04-02  
**Baseline real:** `674195e90446`  
**Estado actual:** `library-first-hybrid` funciona, pero auditivamente sigue `WEAK`

---

## 1. Runtime Truth

No cerrar este sprint con métricas cosméticas.

La sesión `674195e90446` confirma:

- `generation_mode = library-first-hybrid`
- `mandatory_midi_hook.materialized = true`
- `coherence_score = 4.7`
- `coherence_verdict = WEAK`
- `family_adherence_rate = 0.5`
- `piano_presence.has_piano = true` pero era casi todo por hook MIDI
- `repetition_metrics.verdict = mixed`
- `music_source_reuse_ratio = 0.8`

Conclusión:

- el sistema ya no está roto
- el problema ahora es musical y de planificación
- la canción sigue sonando demasiado segmentada, demasiado rígida y demasiado parecida a sí misma

---

## 2. Code Review

### 2.1 Qué estaba mal en v0.1.25

1. `reference_listener.py`
   Los roles loop armónicos todavía podían aceptar material desde carpetas `one shots`. Eso empuja plucks cortados y variantes choppy que rompen continuidad musical.

2. `reference_listener.py`
   El piano estaba siendo contado casi sólo por el hook MIDI. Eso permitía un falso positivo de `piano_presence` sin una capa audio real de keys/rhodes sosteniendo intro/build/break.

3. `reference_listener.py`
   El bajo podía quedar sin anclas suficientes en `build/drop`, dejando huecos grandes aunque el rol estuviera “seleccionado”.

4. `reference_listener.py`
   La extracción de packs seguía aceptando carpetas genéricas del workspace como si fueran packs reales. Eso inflaba o contaminaba la lectura de coherencia.

5. `song_generator.py` + `reference_listener.py`
   La macro-estructura sigue demasiado determinística. No está “rota”, pero sí demasiado rígida:
   `intro -> build -> drop -> break -> drop -> outro`
   con reglas de entrada/salida muy parecidas entre corridas.

### 2.2 Qué ya corrigió Codex antes de este sprint

- rechazo de `one shots` para roles loop (`synth_loop`, `bass_loop`, `perc_loop`, `top_loop`, `vocal_loop`)
- inyección de una capa audio real de piano/keys cuando el sistema sólo tenía hook MIDI
- anclas mínimas de bass en `build/drop`
- limpieza adicional de extracción de pack para no tomar carpetas genéricas del workspace

Eso ya está en código. No lo rehagas ni lo reviertas.

---

## 3. Objetivo Real de v0.1.26

Recuperar **coherencia + musicalidad + estructura usable** sin volver al caos.

La salida buscada no es:

- una pista vacía
- una pista hiper-cortada
- una pista que repite 3 sonidos todo el tema
- una pista “ordenada” pero muerta

La salida buscada sí es:

- estructura clara
- identidad coherente
- más continuidad musical entre secciones
- más vida interna dentro de esa estructura
- audio piano/keys real, no sólo hook MIDI

---

## 4. Trabajo Obligatorio

### P0. Romper el “same song syndrome” sin romper coherencia

Atacar el problema en el path activo, no con métricas inventadas.

Objetivo:

- que dos generaciones consecutivas con misma referencia no caigan en la misma silueta exacta de densidad y capas
- que `intro/build/drop/break/drop/outro` no suene siempre al mismo guion mecánico

Reglas:

- no agregues randomización ciega
- la variación tiene que ser controlada por sección y por rol
- no mezcles packs sin función clara sólo para “diversificar”

Implementación esperada:

- introducir variación real de densidad por sección en `music bus`
- desacoplar parcialmente el patrón de entrada de `synth_loop`, `top_loop` y `perc_loop`
- evitar que `drop A` y `drop B` sean casi el mismo bloque con mínimos cambios cosméticos

### P0. Menos cortes, menos huecos muertos

El reggaeton actual está demasiado “picado”.

Problema audible:

- cortes bruscos
- demasiados espacios donde debería seguir el groove
- layers que entran una vez y desaparecen

Objetivo:

- continuidad rítmica y armónica mejor sostenida
- sin convertir todo en una pared constante

Validar especialmente:

- `bass_loop`
- `perc_loop`
- `top_loop`
- `synth_loop`
- `AUDIO KEYS SUPPORT`

No aceptes:

- capas musicales con 1 o 2 placements en toda la canción salvo justificación muy clara
- drops donde el bajo no sostiene el cuerpo principal
- breaks vacíos por accidente

### P0. Piano audio real, no sólo “piano_presence” de manifest

Nuevo estándar:

- `piano_presence.has_audio_piano = true`
- al menos una capa audio `piano/keys/rhodes` real en `intro`, `build` o `break`
- el hook MIDI puede seguir existiendo, pero ya no alcanza por sí solo

Qué buscar:

- `rhodes`
- `keys`
- `piano`
- `epiano`

Qué no hacer:

- meter piano brillante arriba de todo el drop si rompe el ancla principal
- reemplazar el primary family del tema

La regla musical es:

- `pluck/lead` puede seguir siendo la identidad principal
- `piano/keys` tiene que funcionar como soporte coherente, no como parche decorativo

### P1. Más riqueza tímbrica sin perder identidad

El sistema se encierra en 3-4 sonidos.

Necesitamos:

- más contraste útil
- menos reciclado del mismo material
- sin abrir demasiados packs

Objetivo:

- 1 pack dominante por bus
- 1 secundario sólo si tiene función clara
- más de un color musical dentro del bus music

No aceptes:

- `music_source_reuse_ratio >= 0.8`
- `synth_loop` y `synth_peak` sonando como el mismo gesto todo el tema
- variantes que sólo cambian filename pero no función musical

### P1. Coherencia, no plantilla rígida

La crítica del usuario es correcta:

- quiere estructura
- no quiere escuchar siempre la misma canción

Eso significa:

- no eliminar la estructura
- sí hacer que cada sección tenga una función musical real

Ejemplos de función real:

- intro: presentación y espacio
- build: empuje y preparación
- drop A: statement principal
- break: respiro con soporte armónico útil
- drop B: regreso con diferencia perceptible
- outro: salida lógica

---

## 5. Restricciones

### No tocar sin necesidad

- no reviertas fixes de Codex
- no reabras vocals automáticas
- no metas samples vocales “porque quedan bien”
- no vuelvas a permitir `one shots` como `synth_loop` por accidente

### No maquillar métricas

No cierres el sprint si:

- `coherence_score` sigue `WEAK`
- el audio sigue sonando vacío o excesivamente cortado
- el piano sigue siendo sólo MIDI
- el report dice `SUCCESS` pero la canción sigue auditivamente pobre

### No usar el report como sustituto del manifest

Toda afirmación tiene que salir de:

- `generation_manifests.json`
- manifest nuevo persistido
- session id real
- validación audible del resultado

---

## 6. Criterios de Salida

Para considerar este sprint cerrado, el nuevo manifest debe cumplir:

- `generation_mode = library-first-hybrid`
- `mandatory_midi_hook.materialized = true`
- `piano_presence.has_audio_piano = true`
- `piano_presence.audio_piano_count >= 1`
- `coherence_score >= 6.0`
- `family_adherence_rate >= 0.65`
- `pack_coherence.overall >= 0.6`
- `repetition_metrics.verdict != repetitive`
- `music_source_reuse_ratio < 0.7`
- `vocal_layers_auto = 0`

Y además, auditivamente:

- no debe sonar “trozada”
- no debe sonar como 3 sonidos repitiéndose toda la pista
- `drop B` debe diferenciarse de `drop A`
- `break` debe tener función musical y no ser sólo vacío

---

## 7. Validación Obligatoria

### Código

- `python -m py_compile` sobre archivos tocados
- `tests/test_piano_forward.py`
- `tests/test_selection_coherence.py`

### Runtime

Generar una sesión nueva real con referencia:

- género: `reggaeton`
- estilo: `perreo duro vieja escuela tipo safaera`
- referencia: `libreria\\reggaeton\\ejemplo.mp3`
- bpm: `95`
- key: `Am`

### Revisión del manifest

Reportar explícitamente:

- `session_id`
- `coherence_score`
- `family_adherence_rate`
- `pack_coherence.overall`
- `pack_coherence.music`
- `piano_presence`
- `repetition_metrics`
- `audio_layers` por rol
- qué layer de audio hace el soporte piano/keys
- diferencia real entre `drop A` y `drop B`

---

## 8. Formato del Validation Report

Crear:

- `docs/SPRINT_v0.1.26_VALIDATION_REPORT.md`

Estructura obligatoria:

1. `Runtime Truth`
2. `Manifest Evidence`
3. `Audible Outcome`
4. `Code Changes`
5. `Open Bugs`
6. `Verdict`

Reglas:

- no uses `SPRINT CERRADO CON ÉXITO` si `coherence_score` sigue en `WEAK`
- no ocultes métricas malas
- no digas “piano presente” si sigue siendo sólo hook MIDI
- si el audio sigue muy cortado o muy parecido a la corrida anterior, escribirlo explícitamente

---

## 9. Resumen para GLM

Tu trabajo no es “hacer más variación”.

Tu trabajo es este:

- conservar coherencia
- reducir lo choppy
- recuperar musicalidad
- meter piano audio real
- evitar la sensación de “misma canción siempre”
- no reabrir vocals

Si la nueva corrida sigue sonando rígida, vacía o demasiado loopeada, el sprint no está cerrado.