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

# Sprint v0.1.24 - GLM Runtime Truth, Hybrid Recovery, Anti-Same-Song Real

**Owner:** GLM via OpenCode  
**Reviewer:** Codex  
**Fecha:** 2026-04-02  
**Baseline real vigente:** `6df5c445aa1e`  
**Estado de cierre v0.1.23:** no cerrado

---

## 1. Verdad operativa despues del review de Codex

El reporte [SPRINT_v0.1.23_VALIDATION_REPORT.md](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.23_VALIDATION_REPORT.md) no cierra el sprint y quedo desactualizado en dos puntos importantes:

1. el claim de `MCP timeout` no es valido como blocker general
2. hoy si existe una sesion nueva persistida: `6df5c445aa1e`

Codex verifico runtime real:

- `get_session_info()` responde bien contra Live
- no hay bloqueo general del MCP

Codex verifico la sesion nueva `6df5c445aa1e` en [generation_manifests.json](C:\Users\ren\.abletonmcp_ai\generation_manifests.json):

- `genre = reggaeton`
- `style = perreo duro vieja escuela tipo safaera`
- `reference_path = None`
- `generation_mode = midi-first`
- `mandatory_midi_hook.materialized = false`
- `piano_presence.piano_layer_count = 0`
- `repetition_metrics = None`
- `coherence_metrics = None`
- `tracks_blueprint = 0`

Conclusion:

- GLM no valido el flujo pedido con referencia
- la sesion nueva no demuestra el path `library-first-hybrid`
- el trabajo en `reference_listener.py` por si solo no alcanza si el runtime cae otra vez a `midi-first`

---

## 2. Code Review de Codex sobre lo que hizo GLM

### A. El reporte confunde ausencia de validacion con bloqueo real

GLM dejo `MCP timeout` como explicacion principal, pero Codex comprobo que el MCP si responde.

Regla nueva:

- no volver a usar `MCP timeout` como excusa general sin comando reproducible, timestamp y evidencia concreta

### B. GLM mejoro el path activo, pero dejo dos bugs reales en la variacion armonica

GLM agrego variacion para `synth_loop` y `bass_loop` en [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py). La idea iba en la direccion correcta, pero habia dos bugs:

1. la variacion seccional seguia usando el `step` del sample global, no el del sample alternativo real
2. si solo quedaba un sample alternativo en `positions_by_sample`, `add_layer()` seguia atribuyendo el layer al asset global en vez del sample realmente usado

Eso hace que:

- la variacion pueda quedar mal cuantizada
- el manifest pueda mentir sobre que sample sono realmente

Codex ya dejo corregido esto.

### C. Los tests nuevos de GLM eran demasiado debiles

GLM agrego tests que verificaban principalmente:

- que existan constantes
- que ciertas secciones esten en un set

Eso no prueba comportamiento runtime.

Codex ya endurecio la suite con un test que valida el path real:

- `build_arrangement_plan()` debe usar el sample armonico alternativo
- y debe respetar su `loop_step` real

### D. La sesion nueva demuestra otro problema mas importante

La sesion `6df5c445aa1e` no uso referencia:

- `reference_path = None`
- `reference_name = None`

Entonces:

- no valida el caso pedido por el sprint
- no prueba anti-same-song sobre el flujo referenciado
- no prueba coherencia de libreria
- no prueba el hibrido con hook + piano + libreria

### E. La regresion estructural sigue abierta

Aunque GLM agrego blueprints nuevos en [song_generator.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\song_generator.py), no hay evidencia de que el usuario este escuchando eso en el path real.

Hasta que no exista una sesion nueva persistida que:

- use referencia
- quede en `library-first-hybrid`
- y materialice diferencias seccionales reales

no se puede dar por cerrada la recuperacion de creatividad.

---

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

### reference_listener.py

Codex corrigio dos bugs de la variacion armonica:

1. el `step` ahora se resuelve desde el sample realmente usado por seccion
2. `add_layer()` ya no adjudica automaticamente el layer al asset global cuando el sample real era otro

Esto afecta el path activo de `build_arrangement_plan()`.

### test_piano_forward.py

Codex agrego un test real de comportamiento:

- valida que `build_arrangement_plan()` materialice variacion armonica con `loop_step` del sample alternativo

GLM no debe revertir estos cambios.

---

## 4. Objetivo real del sprint

Cerrar la brecha entre:

- cambios en `reference_listener.py`
- y el resultado real que escucha el usuario

La prioridad absoluta ahora es:

1. volver al flujo `library-first-hybrid`
2. usar referencia real
3. recuperar creatividad sin perder coherencia
4. persistir metricas reales en manifest

No quiero otro sprint con mejoras locales correctas pero validadas sobre una sesion que no usa referencia.

---

## 5. Reglas no negociables

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

2. No reabrir vocals automaticas.

3. No usar sesiones sin referencia para cerrar un sprint de coherencia referenciada.

4. No usar `midi-first` como cierre valido para este objetivo.

5. No cerrar el sprint si la sesion nueva no cumple:
   - `reference_path != None`
   - `generation_mode = library-first-hybrid`
   - `mandatory_midi_hook.materialized = true`
   - `piano_presence.piano_layer_count >= 1`

6. No declarar creatividad recuperada si la diferencia sigue estando solo en adornos.

7. No aceptar tests que solo validen constantes o listas.

---

## 6. Trabajo obligatorio para GLM

### P0. Recuperar el path correcto de generacion

Tenes que identificar por que la sesion nueva `6df5c445aa1e` cayo en:

- `reference_path = None`
- `generation_mode = midi-first`
- `tracks_blueprint = 0`

Eso es prioridad maxima.

Hay que cerrar el wiring desde:

- request de generacion
- lectura de referencia
- `build_arrangement_plan()`
- materializacion
- persistencia de manifest

Hasta que eso no cierre, el resto de los claims musicales sigue en el aire.

### P1. Anti-same-song en el path que realmente escucha el usuario

Una vez recuperado el flujo referenciado:

- demostrar que `synth_loop` y/o `bass_loop` varian por seccion
- demostrar que la estructura no cae siempre en el mismo blueprint percibido
- demostrar que la creatividad vuelve al material principal

No alcanza con:

- cambiar fills
- cambiar perc loops
- cambiar FX

### P2. Persistencia real de metricas

Tenes que dejar funcionando de verdad en la sesion nueva:

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

No como `None`.
No como placeholder.
No como objeto vacio.

### P3. Hibrido real

Quiero evidencia real de:

- referencia cargada
- libreria usada
- hook MIDI creado
- piano/keys presentes
- audio y MIDI conviviendo

Si sigue saliendo `midi-first`, el sprint no cierra.

### P4. Validacion de verdad del manifest

Comparar la sesion nueva contra el set real y asegurar:

- que el manifest no miente sobre los samples usados
- que los layers armonicos reflejan el sample realmente materializado
- que la variacion seccional no queda perdida al persistir

---

## 7. Casos de test obligatorios

Minimo tenes que dejar o endurecer tests para:

1. flujo con referencia que no termine en `reference_path = None`
2. `generation_mode = library-first-hybrid` cuando hay referencia y plan hibrido
3. persistencia real de `coherence_metrics`
4. persistencia real de `repetition_metrics`
5. persistencia real de `piano_presence`
6. materializacion real del hook MIDI
7. variacion armonica seccional usando el sample real, no el asset global

No borres tests de Codex.

---

## 8. Validacion final obligatoria

Al final del sprint tenes que generar una sesion nueva real con:

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

Y demostrar con `session_id` nuevo y persistido:

1. `reference_path` presente
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. `coherence_score >= 6.5`
7. cero vocals automaticas

### Criterio auditivo obligatorio

En el report final tenes que explicar:

1. que cambio en intro/build/drop/break
2. que material principal dejo de repetirse igual
3. como se mantuvo coherencia sin volver a la misma cancion

Si no podes explicarlo con precision, no esta cerrado.

---

## 9. Formato obligatorio del validation report

El archivo final debe llamarse:

- `SPRINT_v0.1.24_VALIDATION_REPORT.md`

Y debe tener estas secciones, en este orden:

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

### Reglas del report

1. No usar `MCP timeout` sin evidencia reproducible.
2. No usar sesiones sin referencia para cerrar este sprint.
3. No usar lenguaje hipotetico tipo `should now`.
4. Si algo sigue abierto, poner `OPEN`.
5. Si la sesion cae en `midi-first`, decirlo explicitamente.

---

## 10. Definicion de done real

Este sprint solo cierra si:

1. el flujo vuelve a usar referencia real
2. el resultado vuelve a ser `library-first-hybrid`
3. la creatividad se recupera en el material principal
4. la coherencia sube en vez de bajar
5. el manifest refleja la verdad runtime

Si falla cualquiera de esos cinco puntos, no esta cerrado.