# Sprint v0.1.4 - Cerrar Integracion Real y Evidencia Runtime

Fecha: 2026-03-30

Este sprint reemplaza a `docs/SPRINT_v0.1.3_NEXT.md` como sprint activo.

## Objetivo

Pasar de "hay wiring parcial y tests unitarios" a "hay evidencia runtime de que el flujo real usa esas mejoras".

## Estado de partida real

- `reference_listener.py` mejoro: ahora setea contexto por seccion y pasa `section_kind`/`section_energy` en seleccion por variante.
- `sample_selector.py` tiene `SECTION_ROLE_PROFILES`, `record_section_selection()` y `_calculate_joint_score()`.
- No esta demostrado todavia que el `joint scoring` del `SampleSelector` afecte la generacion real end-to-end.
- `temp\smoke_test_async.py` existe, pero Kimi lo habia dejado con `SERVER_PATH` roto; eso ya fue corregido.
- `.gitignore` ahora vuelve a ignorar solo `temp/`; no debe volver a esconder scripts globalmente.

## Tarea 1 - Probar section-aware y joint scoring en el flujo real

Problema:

- hoy hay mejora parcial en `reference_listener.py`
- pero no alcanza con que exista `set_section_context()`
- hace falta demostrar que el flujo real cambia picks por seccion y que el scoring conjunto entra en juego

Haz esto:

1. identificar el camino exacto de generacion que se usa en runtime
2. verificar si el scoring principal pasa por `SampleSelector._calculate_sample_score()`
3. si no pasa, cablearlo o dejar explicitamente documentado que `reference_listener.py` usa su propia heuristica
4. capturar logs reales de una generacion con `SECTION_CONTEXT`
5. capturar logs reales de `JOINT_SCORE`, o documentar con evidencia que esa parte sigue sin usarse

Archivos probables:

- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/reference_listener.py`
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/sample_selector.py`
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py`

Criterio de salida:

- hay evidencia runtime de `SECTION_CONTEXT`
- queda claro si `JOINT_SCORE` participa o no participa del flujo real
- no se vuelve a usar lenguaje tipo "activo" sin prueba

## Tarea 2 - Validar async con Live real

Problema:

- la infraestructura async existe
- la validacion documentada sigue floja
- el smoke test estuvo roto por path y eso invalida parte del claim anterior

Haz esto:

1. ejecutar `python temp\smoke_test_async.py` con Live abierto
2. probar `generate_song_async`
3. probar `generate_track_async --use-track`
4. revisar polling, resultado final y tracks creados
5. guardar evidencia minima en el sprint o handoff

Archivos:

- `temp\smoke_test_async.py`
- `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py`

Criterio de salida:

- `queued -> running -> completed` o un fallo claro y reproducible
- resultado util en `get_generation_job_status`
- si falla, el bug queda localizado

## Tarea 3 - Unificar scripts y rutas canonicas

Problema:

- hay docs que todavia apuntan a `smoke_test_async.py` en root
- el script real vive en `temp\`
- esto vuelve a generar handoffs falsos o instrucciones rotas

Haz esto:

1. corregir docs y handoffs para usar la ruta canonica real
2. revisar si conviene mantener el script en `temp\` o devolverlo a root
3. si lo dejas en `temp\`, asegurate de que la documentacion sea consistente
4. no vuelvas a ocultar scripts globalmente con `.gitignore`

Archivos:

- `SMOKE_TEST_ASYNC.md`
- `KIMI_K2_ACTIVE_HANDOFF.md`
- `KIMI_K2_BOOTSTRAP.md`
- docs que mencionen `smoke_test_async.py`

Criterio de salida:

- una sola ruta canonica
- sin referencias viejas en docs activas

## Tarea 4 - Endurecer la documentacion de evidencia

Problema:

- Kimi sigue marcando "completado" donde solo hay compile + narrativa
- eso vuelve inutiles los handoffs

Haz esto:

1. en cada cambio importante, separar:
   - codigo existe
   - codigo cableado
   - runtime validado
2. no uses porcentajes globales tipo `100%`
3. si falta runtime, decirlo literal
4. si un documento historico sobredeclara, agregar correccion en vez de ignorarlo

Archivos:

- `docs/SPRINT_v0.1.4_CHANGES.md` cuando cierres este sprint
- `KIMI_K2_ACTIVE_HANDOFF.md`

Criterio de salida:

- proximo handoff usable por otro agente sin re-auditoria completa

## Tarea 5 - Solo despues: seguir mejorando seleccion musical

No entres primero a esta tarea.

Primero cierra integracion y validacion.

Si Tareas 1-4 quedan bien, despues recien:

1. endurecer coherencia por pack entre secciones
2. validar que groove templates reales cambian el ritmo
3. revisar scoring musical sobre loops de reggaeton

## Reglas duras

- usa PowerShell, no bash
- usa rutas absolutas de Windows en docs
- no declares exito por compilacion sola
- no declares exito por logs inventados o esperados
- si contradicen diff, codigo y doc, gana el codigo
- si contradicen codigo y runtime, gana el runtime

## Comandos utiles

```powershell
python temp\smoke_test_async.py --use-track
python AbletonMCP_AI\AbletonMCP_AI\MCP_Server\tests\test_sample_selector.py
Get-Content "$env:APPDATA\Ableton\Live 12.0.15\Preferences\Log.txt" -Tail 120
rg -n "smoke_test_async.py|SECTION_CONTEXT|JOINT_SCORE" .
```