ableton-mcp-ai/docs/SPRINT_v0.1.26_NEXT_GLM.md

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.