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

# Sprint v0.1.23 - GLM Coherence-First, Anti-Same-Song, Zero Auto Vocals

**Owner:** GLM via OpenCode  
**Reviewer:** Codex  
**Fecha:** 2026-04-01  
**Baseline real vigente:** `ccb998a08796`  
**Estado de cierre v0.1.22:** no cerrado

---

## 1. Verdad operativa despues del review de Codex

El archivo [SPRINT_v0.1.22_NEXT.md](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.22_NEXT.md) que dejo Minimax no es un handoff correcto de sprint. Es mas bien un changes report parcial con conclusiones inestables y con preguntas abiertas que no estaban cerradas en codigo ni en runtime.

Codex verifico contra:

- [generation_manifests.json](C:\Users\ren\.abletonmcp_ai\generation_manifests.json)
- [server.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py)
- [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py)
- [song_generator.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\song_generator.py)

Verdad real observada hoy:

1. el `last_generation_id` vigente es `ccb998a08796`
2. los manifests recientes siguen sin reflejar cierre real de coherencia
3. `generation_mode` sigue viniendo `None` en sesiones recientes
4. `piano_presence.piano_layer_count` sigue en `0` en sesiones recientes
5. `repetition_metrics` sigue ausente en sesiones recientes
6. el hook MIDI no falla siempre, pero sigue siendo inestable
7. la sensacion auditiva del usuario es correcta: el sistema esta cayendo otra vez en la misma cancion

No generes otra sesion hasta que cierres las causas de codigo de esa repeticion.

---

## 2. Code Review de Codex: causas probables de "misma cancion siempre"

### A. La variacion por seccion esta sesgada a roles secundarios

En [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py):

- `SECTION_VARIATION_ROLES` existe
- el bloque de `section_samples` en `build_arrangement_plan()` aplica variacion real solo a:
  - `perc`
  - `perc_alt`
  - `top_loop`
  - `synth_peak`
  - `atmos`

Pero los roles que mas identidad musical fijan siguen casi globales:

- `bass_loop`
- `synth_loop`

Eso hace que el track cambie adornos, pero no cambie el nucleo musical.
Resultado audible: misma cancion, misma paleta, mismo centro melodico.

### B. La macro-estructura sigue demasiado templada

En [song_generator.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\song_generator.py):

- `_build_sections()` sigue trabajando sobre blueprints muy repetidos
- reaparecen constantemente patrones tipo:
  - `INTRO`
  - `DROP A`
  - `BREAKDOWN`
  - `BUILD B`
  - `DROP B`

Aunque exista `variant_seed`, el esqueleto alto nivel sigue demasiado similar entre generaciones.
Resultado audible: el usuario percibe que la estructura siempre vuelve al mismo guion.

### C. El anti-loop no puede declararse resuelto si toca helpers no demostradas como activas

Minimax dio demasiado peso a cambios en helpers y a claims tipo "active path fixed", pero Codex verifico que:

- `_apply_clip_consolidation()` sigue sin demostrar uso real en el path runtime final
- tocar una helper sin probar efecto en la sesion final no cuenta como cierre

GLM tiene que demostrar con trazabilidad que el fix que haga corre en la generacion real.

### D. La politica vocal seguia ambigua en el plan

Aunque ya habia filtros y purgas posteriores, [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py) seguia construyendo posiciones vocales dentro de `build_arrangement_plan()`.

Codex ya cerro ese leak adicional:

- se bloquea `vocal_loop`
- se bloquea `vocal_shot`
- se fuerza `vocal_alt = None`
- se saca `vocal_shot` del `role_match_map`

Eso ya no debe reabrirse.

### E. La creatividad se movio del material principal a los bordes

Hoy el sistema puede variar:

- fills
- percusiones secundarias
- atmos
- algun peak synth

Pero no esta variando suficiente:

- la armonia principal
- el loop musical dominante
- el bajo dominante
- la distribucion de motivos entre secciones

Eso no es creatividad estructural.
Es decoracion.

---

## 3. Fixes ya aplicados por Codex en este turno

Codex dejo fixes concretos antes de entregarte este sprint:

### reference_listener.py

- bloqueo adicional de vocals dentro de `build_arrangement_plan()`
- ya no se deja pasar `selected["vocal_loop"]`
- ya no se deja pasar `selected["vocal_shot"]`
- `vocal_alt` queda forzado a `None`
- `vocal_shot` fue removido del mapa de variacion por seccion

### test_piano_forward.py

- test endurecido para verificar que:
  - `plan["layers"]` no contenga roles vocales
  - `plan["section_samples"]` no contenga claves vocales

GLM no debe revertir estos cambios.

---

## 4. Objetivo real del sprint

Recuperar dos cosas al mismo tiempo:

1. coherencia real
2. creatividad real

Y hacerlo sin reabrir:

- vocals automaticas
- manifests mentirosos
- helpers no activas disfrazadas de fix

La meta no es "hacer mas compleja la generacion".
La meta es que deje de sonar al mismo tema con ropa distinta.

---

## 5. Reglas no negociables

1. Trabajar solo en el arbol canonico:
   - `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts`

2. No tocar wrappers ni config MCP salvo bug concreto reproducido.

3. No reabrir vocals automaticas:
   - no seleccion
   - no section plan
   - no materializacion
   - no persistencia
   - no tracks `AUDIO VOCAL *`

4. No declarar anti-loop resuelto si el cambio esta en una helper no probada en runtime.

5. No cerrar el sprint con manifests viejos o inventados.

6. No cerrar el sprint sin una sesion nueva persistida y verificable.

7. No aceptar como "creatividad" cambiar solo perc/fills/FX.

8. No degradar coherencia armonica por buscar variedad.

---

## 6. Trabajo obligatorio para GLM

### P0. Atacar la identidad musical principal, no solo adornos

Revisar en [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py):

- `build_arrangement_plan()`
- `section_samples`
- `SECTION_VARIATION_ROLES`
- logica de `bass_positions`
- logica de `synth_positions`

Objetivo:

- `synth_loop` no puede quedar fijo globalmente durante toda la cancion
- `bass_loop` no puede quedar fijo globalmente durante toda la cancion
- tiene que existir variacion musical principal por seccion, no solo por FX

No significa randomizar sin control.
Significa introducir contraste controlado y coherente.

### P1. Recuperar creatividad estructural en song_generator.py

Revisar en [song_generator.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\song_generator.py):

- `SECTION_BLUEPRINTS`
- `SECTION_BLUEPRINT_VARIANTS`
- `_build_sections()`
- `SectionVariationManager`
- `PhrasePlan`

Objetivo:

- bajar la repeticion de la macro-estructura
- ampliar diversidad real de blueprints para reggaeton/perreo
- evitar que todas las generaciones vuelvan al eje:
  - intro
  - drop a
  - breakdown
  - build b
  - drop b

Quiero variedad controlada de:

- duraciones
- orden de break/build
- distribucion de densidad
- rol del piano/keys entre intro, break y build

### P2. Variacion armonica coherente, no caos

Tenes que reforzar la coherencia sin aplanar creatividad.

Objetivo musical:

- una familia primaria clara
- familias secundarias compatibles
- mas presencia de `piano/keys/rhodes`
- menos sensación de "mismo loop completo pegado en todas las secciones"

Pero:

- no rompas la tonalidad
- no rompas el hook
- no metas sonidos que parezcan de otro track

### P3. Persistencia y metricas de verdad

Hoy los manifests recientes siguen viniendo flojos:

- `generation_mode = None`
- `piano_presence = 0`
- `repetition_metrics = None`

Eso no puede seguir.

GLM tiene que cerrar el wiring real para que la sesion nueva persistida refleje:

- `generation_mode`
- `piano_presence`
- `repetition_metrics`
- `coherence_metrics`

No como metadata de papel.
Como verdad del resultado generado.

### P4. Cero vocals automaticas end-to-end

Verificar otra vez todo el path:

- seleccion
- arrangement plan
- materializacion
- manifest

Si aparece una sola capa vocal auto-generada, el sprint no cierra.

---

## 7. Casos de test obligatorios

Minimo tenes que dejar o endurecer tests para:

1. variacion seccional de `synth_loop` o material armonico principal en el path activo
2. variacion seccional de `bass_loop` o bajo principal en el path activo
3. ausencia total de roles vocales en `section_samples`
4. ausencia total de roles vocales en `layers`
5. persistencia real de `repetition_metrics`
6. persistencia real de `generation_mode`
7. persistencia real de `piano_presence`
8. no regresion de coherencia basica

No borres tests de Codex.
No reemplaces tests concretos por asserts vagos.

---

## 8. Validacion final obligatoria

Al final del sprint tenes que hacer una generacion nueva real con:

- `genre = reggaeton`
- `style = perreo duro vieja escuela tipo safaera`
- referencia:
  - `libreria\reggaeton\ejemplo.mp3`

Y tenes que demostrar con `session_id` nuevo y persistido:

1. `coherence_score >= 6.5`
2. `generation_mode = library-first-hybrid`
3. `mandatory_midi_hook.materialized = true`
4. `piano_presence.piano_layer_count >= 1`
5. `repetition_metrics.verdict != repetitive`
6. cero vocals automaticas
7. evidencia audible de que no es la misma cancion que la anterior

### Criterio auditivo obligatorio

En el report final no alcanza con metrics.
Tenes que describir con precision:

- que cambio entre intro/build/drop/break
- que material principal varia
- que sonidos dejaron de repetirse igual
- por que ya no suena al mismo track de siempre

Si no podes explicarlo claramente, no esta cerrado.

---

## 9. Formato obligatorio del validation report

El archivo final debe llamarse:

- `SPRINT_v0.1.23_VALIDATION_REPORT.md`

Y debe tener estas secciones, en este orden:

1. `Runtime Truth`
2. `Code Changes`
3. `Code Review Findings Addressed`
4. `Fresh Session Evidence`
5. `Manifest Metrics`
6. `Anti-Same-Song Validation`
7. `Manual Vocal Policy Validation`
8. `Open Issues`
9. `Verdict`

### Reglas del report

1. No usar `session_id` viejos.
2. No usar frases tipo `should now`.
3. No escribir `fixed` si no hay evidencia en sesion nueva.
4. Si algo no cerro, ponerlo como `OPEN`.
5. Si la creatividad sigue floja, decirlo.

---

## 10. Definicion de done real

Este sprint solo cierra si:

1. la cancion deja de sentirse como la misma estructura con los mismos sonidos
2. la creatividad vuelve al material principal, no solo a adornos
3. la coherencia sube en vez de bajar
4. no hay ninguna vocal automatica
5. el manifest final refleja la verdad real del runtime

Si falta cualquiera de esos cinco puntos, el sprint no esta cerrado.