# Sprint v0.1.5 - Cerrar Async Real y Probar Section-Aware de Punta a Punta Fecha: 2026-03-30 Este sprint reemplaza a `docs/SPRINT_v0.1.4_NEXT.md` como sprint activo. ## Estado de partida real - `temp\smoke_test_async.py` ya no falla por parsing ni por shape incorrecto de `get_tracks` - evidencia actual en `temp\smoke_test_async_report.json`: - `connection_check`: PASS - `launch_async_job`: PASS - `verify_tracks_created`: PASS - `poll_job_status`: FAIL por timeout a 300s - durante ese timeout la cantidad de tracks subio de `122` a `165`, asi que el job estaba haciendo trabajo real - `reference_listener.py` sigue usando logica hardcoded en `_select_candidate()` y no hay evidencia runtime de `JOINT_SCORE` ## Objetivo Pasar de "hay trabajo real ocurriendo pero sin cierre observable" a "el sistema async y el section-aware tienen evidencia end-to-end o un bug localizado con precision". ## Tarea 1 - Instrumentar el job async de verdad Problema: - el smoke test ya no esta roto en lo basico - ahora el problema real es que el job no completa dentro del timeout de 300s - hoy no hay suficiente visibilidad de en que etapa exacta se queda Haz esto: 1. agregar mas `stage` updates en el flujo async real 2. guardar `last_progress_at` o `last_command` en `_generation_jobs` 3. si el job sigue vivo, el polling debe mostrar progreso util 4. si el job queda colgado, debe quedar claro en que etapa exacta Archivos: - `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py` - `temp\smoke_test_async.py` Criterio de salida: - `get_generation_job_status` devuelve informacion util mientras corre - el reporte final incluye `last_status`, `last_stage` y evidencia de progreso real ## Tarea 2 - Determinar si el timeout es lentitud o cuelgue Problema: - hoy sabemos que el job crea tracks, pero no si termina tarde o si se queda en loop - el proceso del smoke test puede seguir vivo despues del timeout porque el worker sigue corriendo Haz esto: 1. correr `python temp\smoke_test_async.py --use-track --genre reggaeton --bpm 95` 2. medir cuanto tarda hasta completarse de verdad 3. si tarda mas de 300s pero completa, documentarlo y ajustar timeout/reporting 4. si no completa, localizar el bucle o cuello de botella Pistas actuales: - logs muestran muchos `get_track_routing` - logs muestran `ZAIJudges` con `429` y backoff - logs muestran creacion sostenida de tracks y devices Criterio de salida: - queda claro si el problema es performance, bloqueo o falta de cierre de estado ## Tarea 3 - Probar o cablear section-aware de verdad Problema: - `reference_listener.py` setea contexto por seccion - pero `_select_candidate()` sigue usando logica hardcoded - no hay evidencia runtime de `SECTION_CONTEXT` ni `JOINT_SCORE` en generacion real Haz esto: 1. capturar logs reales de una generacion con `SECTION_CONTEXT` 2. demostrar si `JOINT_SCORE` entra o no entra 3. si no entra, cablear la seleccion real al `SampleSelector` o documentar explicitamente que sigue desacoplada Archivos: - `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/reference_listener.py` - `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/sample_selector.py` Criterio de salida: - hay evidencia runtime o fix real, no solo narrativa ## Tarea 4 - Reducir latencia inutil en la ruta de generacion Problema: - los `429` de `ZAIJudges` y ciertos loops de consultas a Live pueden inflar la duracion del job Haz esto: 1. medir cuanto aportan los retries de Z.ai al tiempo total 2. revisar si `get_track_routing` o consultas similares estan ocurriendo demasiado 3. si hace falta, agregar modo smoke-test con judges desactivados o mas agresivamente cacheados Archivos: - `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/zai_judges.py` - `AbletonMCP_AI/AbletonMCP_AI/MCP_Server/server.py` Criterio de salida: - una corrida de smoke test tiene tiempo explicable y acotado ## Tarea 5 - Solo despues seguir con mejoras musicales No entres primero aca. Primero cierra Tareas 1-4. Recien despues: 1. mejorar coherencia musical por seccion 2. hacer que groove extraction afecte el ritmo real 3. seguir afinando reggaeton selection ## Reglas duras - usa PowerShell, no bash - usa rutas absolutas de Windows en docs - no declares exito por compilacion sola - no inventes root causes si no estan respaldados por codigo o runtime - si el smoke test cambia de fallo, actualiza el handoff activo ## Comandos utiles ```powershell python temp\smoke_test_async.py --use-track --genre reggaeton --bpm 95 Get-Content temp\smoke_test_async_report.json Get-Content "$env:APPDATA\Ableton\Live 12.0.15\Preferences\Log.txt" -Tail 200 rg -n "_generation_jobs|last_progress_at|stage|get_track_routing" AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py ```